Each process is designed to achieve a specific objective, taking defined inputs (information or products) and transforming them through a series of activities into defined outputs. These processes provide the framework within which the PRINCE2 principles are upheld and the themes are actively applied. There are seven distinct processes in the PRINCE2 model.

The flow between these processes follows a logical progression, often visualized in process model diagrams. A typical project starts pre-project, moves into Starting Up a Project (SU), which triggers Directing a Project (DP) by the Project Board. DP authorizes Initiating a Project (IP). Once initiated, the project moves into delivery stages, cycling between Controlling a Stage (CS) and Managing Product Delivery (MP), with Managing a Stage Boundary (SB) occurring between stages. Finally, Closing a Project (CP) concludes the lifecycle. Detailed diagrams sometimes use color-coding to indicate frequency: blue for processes run once per project (like SU, IP, CP), green for once per stage (like SB), and orange/red for processes run multiple times within a stage (like CS, MP, DP activities).

The structure of the PRINCE2 processes inherently builds in crucial governance and control points. Processes like Starting Up a Project, Initiating a Project, Managing a Stage Boundary, and Closing a Project are specifically designed to provide the Project Board with formal opportunities to assess the project’s viability, authorize the commitment of resources, review progress, and confirm successful completion before allowing the project to proceed to the next phase or formally close. This structured gating mechanism, requiring explicit authorization at key junctures, is fundamental to the “Controlled Environments” philosophy underpinning PRINCE2, ensuring active direction and management throughout the project lifecycle.

Please note: Inputs/Outputs listed below are key examples; full lists are in the official guidance.

1. Starting up a Project (SU)

  • Purpose: To perform the necessary checks before project initiation to ensure the prerequisites are in place. It aims to answer the fundamental question: “Do we have a viable and worthwhile project?”. This is a pre-project process designed as a filter to prevent poorly conceived projects from consuming initiation resources.
  • Objective(s): Appoint the initial key roles (Executive and Project Manager); capture lessons from previous projects; design and appoint the core project management team; prepare an outline Business Case; assemble the Project Brief (a summary of the project); define the overall project approach; and create a detailed plan for the Initiation Stage.
  • Key Activities: Appoint Executive & PM; Capture previous lessons; Design & appoint PM team; Prepare outline Business Case; Select project approach & assemble Project Brief; Plan initiation stage.
  • Key Inputs: Project Mandate (the trigger for the process, which can range from a verbal instruction to a detailed document).
  • Key Outputs: Project Brief; Outline Business Case; Initiation Stage Plan; Initial role descriptions; Request to Initiate Project (sent to the Project Board).

2. Directing a Project (DP)

  • Purpose: To enable the Project Board to exercise overall control and be accountable for the project’s success. This involves making key strategic decisions and managing by exception, while delegating the detailed day-to-day management to the Project Manager. This process runs for the entire duration of the project, from initiation to closure.
  • Objective(s): Authorize the start of the initiation stage; Authorize the project itself (based on the PID); Authorize each subsequent management stage (or any necessary Exception Plans); Provide ad-hoc direction and guidance throughout; Ensure post-project benefits reviews are planned; Authorize project closure. Interface with corporate or programme management.
  • Key Activities: Authorize initiation; Authorize the project; Authorize a Stage or Exception Plan; Give ad-hoc direction (responding to reports, requests, exceptions); Authorize project closure.
  • Key Inputs: Request to Initiate Project; Project Initiation Documentation (PID); End Stage Reports; Highlight Reports; Exception Reports; Issue Reports; Requests for advice from the PM; Project closure recommendation.
  • Key Outputs: Decisions and formal authorizations (to initiate, to deliver the project, to proceed to the next stage, to approve an exception plan, to close the project); Ad-hoc direction and guidance provided to the Project Manager.

3. Initiating a Project (IP)

  • Purpose: To establish firm and agreed foundations for the project before significant resources are committed to delivery. It involves detailed planning and defining how the project will be managed and controlled.
  • Objective(s): Agree on any necessary tailoring of PRINCE2; Prepare the detailed management approaches (for Risk, Quality, Change Control, and Communication); Establish the project’s controls and filing structures; Create the overall Project Plan; Refine the Business Case with detailed costs and benefits; Assemble the comprehensive Project Initiation Documentation (PID).
  • Key Activities: Prepare the four management approaches (Risk, Quality, Change, Communication); Set up project controls; Create Project Plan; Refine Business Case; Assemble PID.
  • Key Inputs: Authorization to Initiate Project (trigger from the Project Board via DP); Project Brief (from SU); Initiation Stage Plan (from SU).
  • Key Outputs: Project Initiation Documentation (PID) - this is the main output, consolidating all plans, strategies, controls, the refined Business Case, and role descriptions; Benefits Management Approach; Request to the Project Board to deliver the project.

4. Controlling a Stage (CS)

  • Purpose: This process covers the day-to-day work of the Project Manager during each delivery stage. It focuses on assigning work, monitoring progress, managing issues and risks, reporting to the Project Board, and taking corrective actions to ensure the stage’s objectives are met within the agreed tolerances.
  • Objective(s): Ensure focus on delivering the stage’s products within tolerances; Keep risks and issues under control; Keep the Business Case under review; Deliver the stage’s products to the agreed quality within cost and time constraints; Keep the Project Board informed.
  • Key Activities: Authorize Work Packages to Team Managers/teams; Review Work Package status (via Checkpoint Reports); Receive completed Work Packages; Review the overall stage status against the Stage Plan; Report progress via Highlight Reports; Capture, assess, and manage issues and risks; Escalate issues and risks that exceed tolerances; Take corrective actions within tolerance.
  • Key Inputs: Stage Plan; Project Initiation Documentation (PID); Checkpoint Reports from teams; Completed Work Packages; Issue Register; Risk Register; Quality Register; Configuration Item Records.
  • Key Outputs: Updated Stage Plan (reflecting actuals); Updated Risk, Issue, Quality Registers, and Logs; Highlight Reports to the Project Board; Issue Reports and Exception Reports (if needed); Corrective actions taken; Authorized Work Packages issued.

5. Managing Product Delivery (MP)

  • Purpose: To manage the interface between the Project Manager and the Team Manager(s) or specialist team members responsible for creating the project’s specialist products. It ensures that work is formally assigned, executed, and delivered back to the Project Manager in a controlled manner.
  • Objective(s): Ensure that work assigned to the team is authorized and accepted; Ensure the team understands the requirements (effort, time, cost, quality); Ensure the products delivered by the team meet quality criteria; Keep the Project Manager informed of progress and forecasts.
  • Key Activities: Accept a Work Package (formal agreement between PM and TM/team); Execute the Work Package (the actual creation of the product); Deliver the completed Work Package back to the PM.
  • Key Inputs: Authorization to deliver the Work Package (trigger from CS); The Work Package itself containing product descriptions, tolerances, constraints, reporting requirements etc…
  • Key Outputs: Checkpoint Reports (regular progress updates from TM to PM); Updated Quality Register (as quality checks are performed); Notification to the PM that the Work Package is complete; The completed specialist product(s).

6. Managing a Stage Boundary (SB)

  • Purpose: To allow the Project Board to review the performance of the just-completed stage, assess the continued viability of the project (reviewing the Business Case and Project Plan), and approve the plan for the next stage. This process occurs at the end of every management stage, except for the final one.
  • Objective(s): Assure the Project Board that all products planned for the current stage have been completed and approved; Provide the information needed for the Board to assess the project’s ongoing viability; Obtain authorization and tolerance for the next stage; Record any lessons learned from the completed stage.
  • Key Activities: Plan the next management stage in detail; Update the overall Project Plan; Update the Business Case based on latest information; Update the Risk Register; Report on the performance of the stage just ending; Produce an Exception Plan if the Project Board has requested one (e.g., following an exception in the previous stage).
  • Key Inputs: Current Stage Plan; PID; Checkpoint Reports; Information on completed products and quality checks; Updated Issue, Risk, Quality Registers; Lessons Log; Benefits Management Approach.
  • Key Outputs: Next Stage Plan (or Exception Plan if required); Updated PID, Business Case, Project Plan, Benefits Management Approach, and Risk Register; End Stage Report summarizing the completed stage’s performance; Lessons Report; Request to the Project Board to approve the next stage.

7. Closing a Project (CP)

  • Purpose: To provide a controlled end to the project. This involves verifying that the project has delivered what it set out to, ensuring products are handed over appropriately, and capturing final lessons before formally disbanding the project organization. This process takes place at the end of the final management stage.
  • Objective(s): Verify user acceptance of the project’s products; Ensure the receiving organization is prepared to own and operate the products (support/maintenance arrangements are in place); Review project performance against its original baselines; Assess the benefits already realized and update forecasts for remaining benefits; Ensure all open issues and risks are addressed or transferred; Capture and disseminate final lessons learned.
  • Key Activities: Prepare planned closure (confirming all products delivered and accepted); Prepare premature closure (if the project is terminated early); Hand over products to the operational environment; Evaluate the project’s overall performance; Recommend project closure to the Project Board.
  • Key Inputs: Project Plan; PID; End Stage Report for the final stage; Acceptance records for products; Updated Registers (Issue, Risk, Quality) and Logs (Lessons, Daily).
  • Key Outputs: End Project Report (summarizing overall performance); Lessons Report (final lessons); Updated Benefits Management Approach (with final assessment); Recommendation to the Project Board for closure; Communication confirming project closure.