11.1 The Seven Processes & Process Model

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

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.