ICT Management. > Managing ICT Projects

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

Background

• Context
• Origins
• How we got where we are

Project Definition

• Vision
• Outcomes
• Objectives
• Deliverables
• Method of approach
• Scope
• Constraints
• Exclusions
• Interfaces (how the project fits into overall organisation management - and relationships with partners)
• Assumptions

Initial Business Case

• Needs assessment
• Benefits
• Users (who)
• Numbers
• Marketing and access
• Other players (voluntary and statutory)
• Sustainability

Initial Project Plan

• (Can use software like MS Project)
• Assignments (tasks)
• Timings
  
• Estimated Effort (Staff time)

Budget Quality Plan

• How products will be tested
• (Monitoring, performance indicators)
• Evaluation

Risks

Contingency Plan

Project organisation structure

• (People, roles etc.)

Project Controls

• (Running the project)

Exception Process

• (Under what circumstances we make what changes when things go wrong - who decides.)

What the headings mean

Background

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.

Project Definition

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.

Business Case

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.

Project Plan

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.

Budget

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.

Project Control

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.

Risks

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.

Quality Plan

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.

Summary

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.

Next Section: Product Description or Download the full Project Management Guide (PDF, 676Kb)