Project Management - Project Initiation Document
By Lasa Information Systems Team
Summarise your project in one document which can be referred to when the details get confusing.
Project Initiation Document Headings
- How we got where we are
- Method of approach
- Interfaces (how the project fits into overall organisation management - and relationships with partners)
Initial Business Case
- Needs assessment
- Users (who)
- Marketing and access
- Other players (voluntary and statutory)
Initial Project Plan
- (Can use software like MS Project)
- Assignments (tasks)
- Estimated Effort (Staff time)
Budget Quality Plan
- How products will be tested
- (Monitoring, performance indicators)
Project organisation structure
- (People, roles etc.)
- (Running the project)
- (Under what circumstances we make what changes when things go wrong - who decides.)
What the headings mean
Background is a brief account of how the project got to where it is. Keep it short, most information should appear under the specific headings below.
This section involves working down through a hierarchy of scale, moving from the broad vision for the project through to specific objectives; deliverables and the tasks needed to produce them.
Vision describes the overall change or impact sought such as “combat social exclusion” or “increase access to justice”.
Outcomes deals with the difference that the project will make in the broadest terms. Examples of outcomes would be captured in phrases like – “improve delivery of information”; “reduce duplication of effort between agencies”.
Objectives are the main things that the project will do; they are the purpose of the project and should be readily measurable. You shouldn’t have too many objectives; five objectives would be a lot for most projects.
Deliverables are the things that the project produces. They may be tangible objects like training manuals or less concrete entities like a training course or services.
Method of approach is important for many voluntary sector projects as a way of demonstrating the distinctiveness of a project, or to emphasise the values that are implicit in the project. Examples: “involving users”, “work in partnership with other agencies”.
Scope sets the boundaries to the project, in terms of the work done, client groups, or geographical boundaries.
Constraints describes limitations on the project like time or funding limits.
Exclusions spells out what the project won’t do.
Interfaces deals with the relationship the project will have to the host organisation and with partners.
In writing these different elements it’s worth thinking who they are being written for. The broader elements like “Outcomes” will be of interest to management committees and funders; the greater detail of the Project Plan will be more relevant to the staff doing the work. A PID isn’t produced for its own sake, it’s there to be used: explanations from the different sections can be variously used in funding applications, work plans etc.
The phrase ‘business case’ may seem out of place in a voluntary sector project, but it deals with the justification for the project. What needs will the project meet? Will the benefits it delivers to its users and sponsors justify the cost? This section will contain most of the information required by funders; the numbers and types of users and how they will access the project. Issues like marketing and publicity will be covered, along with links or overlaps with other services and how the project will be sustained when the initial funding runs out.
The business case for voluntary and not-for-profit projects differs from that of commercial projects, which will focus more on income and expenditure. The business case for voluntary sector projects may be more diffuse and less quantifiable, emphasising the needs we aim to meet and the benefits we will deliver.
The development of a Project Plan or schedule lies at the heart of any project. It involves identifying the key tasks of the project and then breaking them down into subtasks. This allows a more accurate estimate of the time the project will take along with a measure of the resources (such as staff time) needed to complete the tasks. The schedule and Gannt charts are a key part of the Project Initiation Document, but are best kept as separate documents. It isn’t necessary to do more than summarise the key tasks in the body of the PID itself.
The project will require a budget and this should be done in the normal way. If a funding application will be made as a part of the project it is helpful to use the project budget as the basis for the application, and to use this to generate the specific information required by the application form.
Project Organisational Structure
Project Organisational Structure will clarify the makeup of the Project Board and of the project team. It is particularly important to be clear on staff roles within the project. So often, difficulties and differences within teams have their roots in uncertainties and competition over roles, and it is helpful to establish roles at the start of the project. The development of an effective team is a key component in the development of a successful project and there is a wealth of literature available on team building.
The Project Manager will report to the Project Board on the progress of the project. This can be done by means of a regular highlight report through the course of the project (perhaps monthly), which will report on activities through the period. The Project Board may meet to discuss this report or it can simply be circulated if the project is going according to plan. At the end of each stage of the project the Project Manager will produce an “end of stage report”. The Board will meet at this point to approve the report and give permission to move on to the next stage.
Effective project management puts effort into managing the risks within a project, focusing attention and allocating resources where it is needed most, rather than spreading them across the whole project. There is perhaps a natural tendency to avoid thinking about those things that are going unpalatably wrong: a defined structure for highlighting and monitoring problems ensures that risks aren’t neglected. This is achieved by keeping a risk log which lists the identified risks for the project and the status of the risk – usually tagged as green, amber or red to give a measure of the severity. Crucially, someone will be given responsibility for managing each risk. The Project Board will review project risks, at least at the end of each stage.
The Quality Plan will lay out key quality criteria, particularly for project deliverables. It is useful to identify the quality measures and to be clear on who will be responsible for seeing that they are met. Each Product Description will give more detail on quality criteria for each deliverable. The quality plan will also deal with how the project will be evaluated as it proceeds. Evaluation often continues after a project is complete, but it is important to build these mechanisms into the project at the planning stage.
Producing a Project Initiation Document can be a substantial piece of work. On smaller projects it can be difficult to know how much effort to put into it. How much detail is commensurate with the size of the project? It’s impossible to give a precise answer, but the work done early in the project will be repaid with interest later on. On a smaller project it is better to respond briefly to all headings than to only complete some of the headings.
- Project Management - A technical project manager?
- Project Management - Controlling the project
- Project Management - Defining the project
- Project Management - Definition Soup
- Project Management - Funding applications
- Project Management - Invitation to tender
- Project Management - Planning and Software
- Project Management - Product Description
- Project Management - The Project Brief
- Project Management - What is Project Management?
- Project Management - Which method?
- Project Management - Why Project Management?
- Project Management - Working with Suppliers
Published: 1st June 2003 Reviewed: 14th May 2006
Copyright © 2003 Lasa Information Systems Team