Project initiation documentation

Purpose:

The purpose of the Project Initiation Documentation is to define the project, in order to form the basis for its management and an assessment of its overall success. The Project Initiation Documentation gives the direction and scope of the project and (along with the Stage Plan) forms the 'contract' between the Project Manager and the Project Board.

The three primary uses of the Project Initiation Documentation are to:

• Ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project
• Act as a base document against which the Project Board and Project Manager can assess progress, issues and ongoing viability questions
• Provide a single source of reference about the project so that people joining the 'temporary organization' can quickly and easily find out what the project is about, and how it is being managed.

The Project Initiation Documentation is a living product in that it should always reflect the current status, plans and controls of the project. Its component products will need to be updated and re-baselined, as necessary, at the end of each stage, to reflect the current status of its constituent parts.

The version of the Project Initiation Documentation that was used to gain authorisation for the project is preserved as the basis against which performance will later be assessed when closing the project.

Fitness for purpose checklist:

• Does the Project Initiation Documentation correctly represent the project?
• Does it show a viable, achievable project that is in line with corporate strategy or overall programme needs?
• Is the project management team structure complete, with names and titles?
• Have all the roles been considered and are they backed up by agreed role descriptions?
• Are the relationships and lines of authority clear?
• If necessary, does the project management team structure say to whom the Project Board reports?
• Does it clearly show a control, reporting and direction regime that can be implemented, appropriate to the scale, risk and importance of the project to corporate or programme management?
• Do the controls cover the needs of the Project Board, Project Manager and Team Managers and satisfy any delegated assurance requirements?
• Is it clear who will administer each control?
• Are the project objectives, approach and strategies consistent with the organisation's corporate social responsibility directive, and are the project controls adequate to ensure that the project remains compliant with such a directive?
• Has consideration been given to the format of the Project Initiation Documentation? For small projects a single document is appropriate. For large projects it is more appropriate for the Project Initiation Documentation to be a collection of stand-alone documents. The volatility of each element of the Project Initiation Documentation should be used to assess whether it should be stand-alone, e.g. elements that are likely to change frequently are best separated out.

Suggested content:

As a minimum the documentation should answer the following fundamental questions about the project:

• What the project is aiming to achieve
• Why it is important to achieve it
• Who will be involved in managing the process and what are their responsibilities
• How and when the project will be undertaken

The Project Initiation Documentation has to answer the above questions to a sufficient level of detail to maintain control of the project. There follows a contents list for the Project Initiation Documentation. Note that the first two (project definition and project approach) are extracted from the Project Brief.

Project definition, explaining what the project needs to achieve. It should include:

• Background
• Project objectives and desired outcomes
• Project scope and exclusions
• Constraints and assumptions
• The user(s) and any other known interested parties
• Interfaces

Project approach, to define the choice of solution that will be used in the project to deliver the business option selected from the Business Case, taking into consideration the operational environment into which the solution must fit

Business Case, describing the justification for the project based on estimated costs, risks and benefits

Project management team structure, a chart showing who will be involved with the project

Role descriptions, for the project management team and any other key resources

Quality Management Strategy, describing the quality techniques and standards to be applied, and the responsibilities for achieving the required quality levels

Configuration Management Strategy, describing how and by whom the project's products will be controlled and protected

Risk Management Strategy, describing the specific risk management techniques and standards to be applied, and the responsibilities for achieving an effective risk management procedure

Communication Management Strategy, to define the parties interested in the project and the means and frequency of communication between them and the project

Project Plan, describing how and when the project's objectives are to be achieved, by showing the major products, activities and resources required on the project. It provides a baseline against which to monitor the project's progress stage by stage

Project controls, summarizing the project-level controls such as stage boundaries, agreed tolerances, monitoring and reporting

Tailoring of PRINCE2, a summary of how PRINCE2 will be tailored for the project.

Source information:

Project Brief

Discussions with user, business and supplier stakeholders for input on methods, standards and controls.

Notes:

The Project Initiation Documentation will need to be formally approved and signed off by the Senior Responsible Owner at the end of the initiation stage of the project. It is typically assembled by the Project Sponsor/Project Director and parts of it may be updated and refined throughout the project life cycle up to and including project closure.

The Project Initiation Documentation is not necessarily one document, but can be an index for a collection of documents, a document which cross-references to a number of other documents or a collection of information in a project management tool. It is likely to be developed through several reiterations. It will have stable elements and dynamics ones which will need to have new versions created as the project progresses.

Ensure that the presentational aspects of the Project Initiation Documentation are thought through. The complete product can be large when all the detailed Product Descriptions and job definitions are included. It can be daunting to receive the whole document, and in some circumstances this could be counterproductive. Use appendices to hold the detail and only publish these when requested.

In the context of OGC construction related projects the Project initiation documentation or its equivalent should be coordinated and owned by the Project Owner with much of the content being provided by the project sponsor, manager, team or external parties as required.

Further information:

See the briefing: Project management; see also document outlines for project brief, project plan and project execution plan.
Managing Successful Projects with PRINCE 2