The project initiation documentation

The last activity of initiating a project is to assemble the project initiation documentation (PID). The PID brings together everything initiation has produced into the basis on which the board will decide whether to authorize the project, and, once approved, the baseline against which the project will be managed and its success assessed. This lesson looks at what the PID contains, how it is assembled and checked, how it relates to the project brief, how it is used during delivery, and the common ways PIDs fail to do their job.

What the PID is for

In plain terms, the PID has two jobs. Before approval, it gives the board the information it needs to decide whether the project should go ahead: what will be delivered, why, how, by whom, when, at what cost, with what risks and under what controls. After approval, it is the project's reference point: the version of the plan, business case, approaches and controls that everyone agreed to. When the project manager later prepares end stage reports, exception reports or the end project report, they compare performance against what the PID set out. At closure, the end project report reviews the project against the original PID.

Because it is a baseline, the PID is not a living document in the sense of being edited freely. Parts of it, such as the project plan and the business case, are updated at each stage boundary and the updated versions are approved by the board. Other parts, such as the management approaches, change only through change control. Many organizations keep the originally approved PID unchanged and maintain later versions alongside it, so that the end project report can compare the project's outcome with what was first agreed.

What the PID contains

Some elements come straight from the project brief and are refined: the project definition and the project approach. Others are created in initiation: the detailed business case, the management approaches, the project plan and the project controls. The PID is therefore not a new document written from scratch but an assembly of products, most of which have been reviewed individually as they were produced. Assembly is the moment to check that they fit together and tell a consistent story.

Project brief and PID compared

Assembling and checking the PID

Assembly is more than stapling documents together. The project manager checks that the products are consistent: that the project plan's costs match the business case, that the controls match the tolerances agreed with the business layer, that the approaches' escalation arrangements match the controls, that the project product description's acceptance criteria are reflected in the quality approach, and that the roles named in the approaches match the team structure. Project assurance usually reviews the assembled PID before it goes to the board.

PRINCE2 also expects the project manager to consider whether the PID is proportionate. A PID that nobody will read is not doing its job. For a small project, a few pages may be enough. For Ridgeline Water, the PID is a single document of about 45 pages, with management approaches as sections and the registers held in the utility's project tool, referenced from the PID rather than printed in it.

A PID checklist validator

The code below automates part of the consistency check. It holds a simplified version of Ridgeline Water's draft PID, checks that every required section is present, and applies three cross-checks: costs match between the plan and the business case, stage tolerances nest within project tolerance, and every acceptance criterion has a quality method.

pid = {
    "sections": ["project definition", "project approach", "business case", "team structure",
                 "management approaches", "project plan", "project controls", "tailoring"],
    "plan_stage_budgets": [160, 1450, 3700, 4290],
    "business_case_cost": 9600,
    "project_cost_tol": 0.05,
    "stage_cost_tols": [0.10, 0.05, 0.04, 0.03],
    "acceptance_criteria": {
        "98 % daily reads": "field read-rate test over 30 days",
        "under 1 in 1,000 bills corrected": None,
        "80 % understand leak alerts": "usability test with 40 customers",
        "portal accessibility": "accessibility audit",
    },
}
required = ["project definition", "project approach", "business case", "team structure",
            "management approaches", "project plan", "project controls", "tailoring"]
problems = []
missing = [s for s in required if s not in pid["sections"]]
if missing:
    problems.append("missing sections: " + ", ".join(missing))
if sum(pid["plan_stage_budgets"]) != pid["business_case_cost"]:
    problems.append("plan and business case costs differ")
stage_tol = sum(b * t for b, t in zip(pid["plan_stage_budgets"], pid["stage_cost_tols"]))
if stage_tol > pid["business_case_cost"] * pid["project_cost_tol"]:
    problems.append("stage tolerances exceed project tolerance")
untested = [c for c, m in pid["acceptance_criteria"].items() if not m]
if untested:
    problems.append("no quality method for: " + "; ".join(untested))
print("PID ready for the board" if not problems else "Fix before submitting:")
for p in problems:
    print(" -", p)

Fix before submitting:
 - no quality method for: under 1 in 1,000 bills corrected

The validator finds one problem, the same one the manual review found: the billing accuracy criterion has no quality method. The fix is to add an end-to-end billing test on sample accounts to the quality management approach and to the pilot stage plan. Everything else is consistent. Automated checks like this are useful on large projects with many products, but they supplement, not replace, an assurance review by people who understand the project.

Requesting authorization to deliver

When the PID is assembled and checked, and managing a stage boundary has produced the plan for the first delivery stage, the project manager sends a request to deliver the project to the board. The board then uses its authorize the project activity, covered in lesson 7. Ridgeline Water's request goes to the board at the end of week 8, with the PID, the pilot stage plan and a short covering note highlighting the key uncertainty (the leak benefit), the external dependency (the billing upgrade) and the pilot's role in resolving both.

Because Ridgeline Water's pilot stage spending is within the general manager's delegated authority, the board can authorize the project and the pilot stage without a council vote. The council or utility board will receive the PID summary for information, and its approval of the main installation contract will be sought at the end of the pilot, as shown in the project plan. Some US cities require council appropriation of the whole project budget at the outset; the project controls should reflect whichever rule applies.

Using the PID during delivery

After approval, the PID is used constantly, even if nobody reads it cover to cover again. Team managers use the product descriptions and quality approach. The project manager uses the controls to decide when to escalate. Project assurance uses the approaches to check that the project is doing what it said it would do. At each stage boundary, the project plan and business case in the PID are updated, and the board approves the updated versions. At closure, the end project report compares what happened with the original PID.

Version control of the PID

Because the PID is a baseline, it needs simple version control. A common arrangement is to give the approved PID a version number such as 1.0, record the date and the board decision that approved it, and store it where it cannot be edited by accident. At each stage boundary, the updated project plan and business case become version 2.0, 3.0 and so on, each linked to the board decision that approved it. Changes to management approaches through change control produce minor versions, such as 1.1, with the issue reference that authorized the change.

The product register, which PRINCE2 7 uses to track the version and status of products, can hold this history. Whatever tool is used, two questions should always be answerable in seconds: which version of the PID is current, and which version did the board originally approve? If either takes an afternoon of searching through email, the project's baselines are not under control.