11.1 The Seven Processes & Process Model

PRINCE2 Practitioner Version 7

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique

2 PRINCE2 7 Method Overview

2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context

3 PRINCE2 Principles (1–4)

3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages

4 PRINCE2 Principles (5–7) & Applying Principles

4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context

5 People Management in Projects

5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management

6 Practices Overview & Business Case

6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios

7 Practices: Organising & Plans

7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring

8 Practices: Quality & Risk

8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application

9 Practices: Issues

9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment

10 Practices: Progress, Sustainability & Application

10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)

11 Processes: Model, Starting, Directing & Initiating

11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project

12 Processes: Controlling a Stage & Product Delivery

12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle

13 Processes: Stage Boundary, Closing & Tailoring

13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)

14 Tailoring, Management Products & Exam Technique

14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps

11.1 The Seven Processes & Process Model

Key Takeaways Explain This Topic AI

PRINCE2 v7 defines exactly seven processes, each triggered by a specific event and each producing defined outputs that feed the next process.

Starting Up a Project and Closing a Project sit at the lifecycle bookends; Directing a Project overlays the entire project and is performed by the Project Board.

Within each stage, Controlling a Stage (Project Manager, day-to-day) and Managing Product Delivery (Team Manager) run in parallel; Managing a Stage Boundary fires between stages.

Processes are 'who does what, when' — they map roles to timed activities, while the principles and themes are the 'why' and 'what'.

Last updated: August 2026

Why processes matter

A PRINCE2 process answers three questions at once: who does what , and when ? The seven principles tell you why the method works; the seven practices tell you what controls you need; the seven processes tell you how the work flows through time . The Practitioner exam weights processes (Learning Outcome LO4) at roughly 30% of the paper , so a precise mental model of triggers, owners, and outputs pays off across many scenario questions.

Processes are event-driven , not phase-driven. A process does not start because a calendar month elapses; it starts because a specific trigger (an input from another process, or an external event such as a Project Mandate) arrives. Each process then transforms its inputs into outputs — management products such as the Project Brief, the PID, Highlight Reports, End Stage Reports — that become the triggers for the next process. This input→process→output chain is what makes PRINCE2 auditable and tailorable.

The seven processes at a glance

# Process Trigger Primary owner Key output

1 Starting Up a Project Project Mandate (from corporate/programme) Executive & PM (designate) Project Brief + request to initiate

2 Directing a Project Authorisation to initiate (overlays whole project) Project Board Decisions, authorisations, ongoing direction

3 Initiating a Project Request to initiate (from Starting Up) Project Manager Project Initiation Documentation (PID)

4 Controlling a Stage Authorised Stage Plan Project Manager Highlight Reports, Work Packages, Issue Reports

5 Managing Product Delivery Work Package accepted by Team Manager Team Manager Quality-checked products + Work Package status

6 Managing a Stage Boundary End of a stage / exception Project Manager End Stage Report + next Stage Plan

7 Closing a Project Request to close (from board) Project Manager End Project Report + Benefits Management Approach

The lifecycle flow

Visualise the model as three concentric rings. The outermost ring is Directing a Project , which the Project Board runs from the moment Initiating is authorised until the project is closed. It is not a stage; it is a continuous overlay of governance that fires its own activities whenever a decision point — stage boundary, exception, closure — arrives.

Inside that ring sit the stage-level processes. Controlling a Stage is the Project Manager's day-to-day loop of assigning work, monitoring progress, and handling issues and risks. It runs in parallel with Managing Product Delivery , the Team Manager's loop of accepting Work Packages, building the specialist products, and reporting status back. These two loops form the stage cycle and repeat for every working stage of the project.

Between stages, Managing a Stage Boundary fires once: the PM assembles the End Stage Report, updates the Project Plan and Business Case, and prepares the next Stage Plan for the board. At the very start, Starting Up a Project runs before the project is even authorised, and Initiating a Project runs once to build the PID. At the very end, Closing a Project runs once to discharge the project and hand products to operational use.

The stage cycle in one line

Controlling a Stage issues Work Packages → Managing Product Delivery builds and returns products → Controlling a Stage monitors and escalates → at stage end, Managing a Stage Boundary reports and plans the next stage → the board (in Directing a Project ) authorises the next stage.

Tailoring the process model

The seven processes are mandatory in the sense that every project must address each of them, but how each is performed is tailorable. A small, low-risk project may run a single delivery stage, collapsing several stage boundaries into one; a large programme-aligned project may add extra reporting cadence inside Controlling a Stage. The v7 manual stresses that the process model is a scaffold, not a checklist: the PM should scale the depth of each activity to the project's risk, size, and complexity, and record the tailoring decisions in the PID.

Worked example: tracing inputs and outputs across a project

Consider a regulatory compliance project triggered by a new data-protection law. The corporate compliance officer issues a one-page Project Mandate ("implement the new standard by Q3"). Starting Up a Project converts this thin mandate into a Project Brief with an outline Business Case ("fine exposure if we miss Q3 is €2m") and a Project Product Description ("a compliant data-handling system"). The board, in Directing a Project, reads the Brief and authorises initiation . Initiating a Project then builds the PID — the full Project Plan, the refined Business Case, and the six management approaches. The board reviews the PID and authorises the project and first stage in a single decision. During that first stage, Controlling a Stage issues Work Packages to the team; Managing Product Delivery builds the data-classification tooling and returns it; the PM reports progress in Highlight Reports. At stage end, Managing a Stage Boundary produces an End Stage Report and the next Stage Plan, which the board authorises. When all stages are complete, Closing a Project produces the End Project Report and a Benefits Management Approach, and the board authorises closure. Each output is the next process's trigger — break the chain and the audit trail breaks with it.

Common exam traps

Confusing the process owner with the process trigger. A question may name the trigger correctly but attribute the work to the wrong role (for example, "the Project Board runs Starting Up"). Always pair trigger with owner: mandate → Executive and PM designate for SU; request to initiate → PM for IP; authorised Stage Plan → PM for Controlling a Stage; accepted Work Package → Team Manager for Managing Product Delivery.

Treating Directing a Project as a stage. It is not. It overlays every stage; it has no Stage Plan of its own and consumes reports produced by the other processes.

Assuming Managing a Stage Boundary runs continuously. It fires once, at the stage boundary (or on an exception), not in parallel with delivery work. Running it mid-stage only happens when an exception forces an early boundary.

Confusing the initiation stage with the first delivery stage. The initiation stage is planned in Starting Up and authorised at the end of Starting Up; the first delivery stage is planned during Initiating and authorised at the end of Initiating. Two different stages, two different authorisation points.

Forgetting that Closing a Project is triggered by the board, not by the PM. The PM requests closure; the board, in Directing a Project, authorises it. The PM then runs Closing a Project to produce the End Project Report.