Study guide
12.1 Controlling a Stage
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
12.1 Controlling a Stage
Key Takeaways Explain This Topic AI
Controlling a Stage (CS) is the Project Manager's day-to-day process that runs continuously throughout every management stage, from stage authorisation to stage boundary.
The PM authorises Work Packages to Team Managers, monitors progress through Checkpoint Reports, and reports upward to the Project Board through Highlight Reports.
When a stage tolerance is forecast to be breached, the PM raises an Exception Report to the Project Board rather than quietly adjusting the plan.
CS handles issues, risks, status review, corrective action, and the receipt of completed Work Packages within a single closed control loop.
Last updated: August 2026
Controlling a Stage (CS) is the process the Project Manager (PM) performs continuously during each management stage. It begins the moment the Project Board authorises a stage (the output of Managing a Stage Boundary ) and ends when the stage closes and the PM submits an End Stage Report. Whereas Starting Up a Project and Initiating a Project are one-off processes, CS runs day after day, often in parallel across several Work Packages, and provides the closed-loop control that keeps the stage within its tolerances.
Purpose and scope
The purpose of CS is simple to state and demanding to perform: assign work, monitor progress, manage issues and risks, report status to the Project Board, take corrective action within tolerance, and escalate when tolerance is forecast to be breached. It is the only process that operates throughout a stage — every other stage-level process is a discrete event at a boundary. The PM does not produce specialist products here; instead, the PM directs, monitors, and integrates the work being produced under Managing Product Delivery .
The scope of CS is deliberately bounded. The PM does not manage the specialist teams directly — that is the Team Manager's job under Managing Product Delivery . The PM manages the stage : its time, cost, scope, quality, risk, and benefits trajectory. The interface between the two processes is the Work Package , which the PM authorises and the Team Manager accepts.
The eight activities of Controlling a Stage
PRINCE2 7 describes eight activities within CS. They are not strictly sequential — the PM loops through them continually as new information arrives from Checkpoint Reports, Issue Reports, or risk updates.
Activity What the PM does Key management products
Authorise a Work Package Issue a Work Package to a Team Manager, setting product scope, tolerances, quality methods, and reporting frequency Work Package, Product Description
Assess progress Review Checkpoint Reports from Team Managers, compare actuals against the Stage Plan, update forecasts Checkpoint Report, Stage Plan, Daily Log
Capture and examine issues and risks Log new issues/risks, assess priority and impact, decide on action or escalation Issue Register, Risk Register, Issue/Risk triggers
Review stage status Stand back and compare overall stage position against plan: are tolerances safe, are dependencies healthy? Stage Plan, Highlight Report draft, Business Case status
Report highlights Send a Highlight Report to the Project Board at the frequency set in the Communication Management Approach Highlight Report
Take corrective action Re-plan, re-allocate work, adjust Work Packages, or update the Stage Plan within the PM's delegated authority Updated Stage Plan, Work Package updates
Escalate Raise an Exception Report to the Project Board when a tolerance is forecast to be breached; receive the board's decision Exception Report, Exception Plan (if instructed)
Receive completed Work Packages Confirm that products have been accepted by the Team Manager and quality-checked, then integrate them into the stage Approved Work Package, Quality Register entries
Key controls
Three controls underpin CS and recur across the Practitioner exam:
Stage tolerances — set by the Project Board when it authorises the stage. The PM monitors the stage against these tolerances (typically time, cost, scope, quality, risk, benefits) and is not free to breach them. If a forecast shows the stage will breach tolerance, the PM must escalate — silently re-baselining a stage is a process violation.
Work Packages — the agreement between PM and Team Manager. Every piece of work in the stage flows through a Work Package; without one, the PM has no formal mechanism to control or accept the work.
Checkpoint and Highlight Reports — the Checkpoint Report flows from Team Manager to PM (frequency set in the Work Package) and the Highlight Report flows from PM to Project Board (frequency set in the Communication Management Approach). Both are time-driven , not event-driven, and together they form the reporting chain that lets the board govern by exception.
When is an Exception Report raised?
A common exam scenario tests the trigger for an Exception Report. The rule is precise: the PM raises an Exception Report when a tolerance is forecast to be breached , not when it has already been breached, and not for every issue. An issue that the PM can resolve within tolerance is handled inside CS through corrective action and the Issue Register — no Exception Report is needed. The Exception Report goes to the Project Board, which then chooses between options such as giving advice, adjusting tolerance, instructing an Exception Plan, halting the project, or ordering premature closure.
A subtle but important point: the PM does not wait until the stage is irrecoverably off track. The trigger is a forecast — a prediction, based on actual progress and remaining work, that the stage tolerance will be exceeded. This is why the assess progress and review stage status activities matter so much: they produce the forecasts that drive the escalation decision.
Day-to-day rhythm
In practice, CS feels like a daily rhythm. The PM opens Checkpoint Reports each morning, updates the Stage Plan, scans the Issue and Risk Registers, takes small corrective actions (perhaps re-assigning a Work Package or tightening a quality check), and at the agreed cadence sends a Highlight Report upward. When something material changes — a key risk materialises, a Work Package is rejected at quality, or the cost forecast drifts outside tolerance — the rhythm shifts into capture/examine/escalate. The Practitioner exam rewards candidates who can distinguish the routine control loop from the exception path, and who can name the management product that moves at each step.