PRINCE2 Agile 2016
Previous Section   Next Section

A.20 Project initiation documentation (PID)

A.20.1 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 authorization for the project is preserved as the basis against which performance will later be assessed when closing the project.

A.20.2 Composition

There follows a contents list for the project initiation documentation. Note that the first two items (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 (see section A.2) 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 (see section A.22) Describing the quality techniques and standards to be applied, and the responsibilities for achieving the required quality levels
  • Configuration management strategy (see section A.6) Describing how and by whom the project’s products will be controlled and protected
  • Risk management strategy (see section A.24) Describing the specific risk management techniques and standards to be applied, and the responsibilities for achieving an effective risk management procedure
  • Communication management strategy (see section A.4) To define the parties interested in the project and the means and frequency of communication between them and the project
  • Project plan (see section A.16) 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.
Previous Section   Next Section