11.4 Initiating a Project

Trigger and purpose

Initiating a Project (IP) is triggered by the request to initiate that emerges from Starting Up a Project, once the Project Board has authorised initiation. It is performed by the Project Manager, with contributions from the Executive (Business Case), Project Assurance, and team members.

Its purpose is to establish firm foundations for the project — to do enough planning, risk thinking, and control design that the board can make an informed decision to authorise the project. PRINCE2 treats initiation as an investment: it costs effort, but it prevents far larger losses from a project that was never viable or was set up with the wrong controls. The output of initiation is the basis against which the whole project will be monitored and controlled.

Activities

The PID — what's inside

The Project Initiation Documentation is the project's contract. It is the single management product that the board reviews at the end of Initiating, and once authorised it becomes the baseline against which the project is controlled. It contains:

• Project Plan — the full project-level plan with stage boundaries and major dependencies.
• Refined Business Case — the detailed justification, costs, benefits, major risks, and timescales.
• Project controls — tolerances (time, cost, scope, quality, benefits, risk), reporting cadence, and escalation paths.
• Management approaches — Risk, Quality, Communication, Change, Sustainability, Benefits (and Configuration where maintained separately).
• Tailoring — how PRINCE2 has been tailored for this project and why.
• Project management team structure and role descriptions — who does what.
• Project Product Description — carried forward from the Project Brief and refined.

A useful memory hook: the PID is the plan, the case, the controls, the rules, and the people. If a scenario asks what is in the PID, look for that combination; if it lists only the Project Plan, it is incomplete.

Authorisation at the end of Initiating

At the end of Initiating, the PM submits the PID plus the first Stage Plan (the plan for the first delivery stage, not the initiation stage) to the Project Board. The board, in Directing a Project, makes a single combined decision: authorise the project and authorise the first stage. This is the formal point at which the project is committed. From here, the project moves into delivery: Controlling a Stage begins, and Directing a Project continues to overlay it.

A subtle exam point: the initiation stage itself was authorised earlier (in authorise initiation, at the end of Starting Up). What the board authorises at the end of Initiating is the project and the first delivery stage. Do not conflate the two authorisations.

Common exam scenarios

• "What document is assembled at the end of Initiating a Project?" — the PID.
• "Where are the Risk Management Approach and Quality Management Approach created?" — in Initiating a Project (not in Starting Up, which only prepares the outline Business Case and Project Product Description).
• "Who authorises the project, and at the end of which process?" — the Project Board in Directing a Project, at the end of Initiating a Project.
• "What triggers Initiating a Project?" — the request to initiate from Starting Up, after the board has authorised initiation.
• "Is the Project Plan created in Starting Up or Initiating?" — in Initiating. Starting Up produces only an Initiation Stage Plan.

Tailoring and proportionality

For a small project, the PID may be a concise folder; the management approaches may be combined into a single document. For a large or regulated project, each approach may be a substantial standalone document with appendices. The v7 manual stresses that initiation should be proportionate to risk and complexity — the goal is firm foundations, not paperwork for its own sake. The tailoring decision recorded in the PID should explain why each approach is scaled the way it is.