12.3 Stage Control & Exception Scenarios (BL4)

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.3 Stage Control & Exception Scenarios (BL4)

Key Takeaways Explain This Topic AI

Controlling a Stage and Managing Product Delivery interact through Work Packages, Checkpoint Reports, issues, and the acceptance hand-back — they are not independent loops.

When an issue or risk is outside the PM's tolerance, the PM raises an Exception Report and the Project Board chooses between advice, tolerance adjustment, an Exception Plan, halting, or premature closure.

A materialised risk is captured and assessed in CS, recorded in the Risk Register, and escalated only if its impact breaches stage tolerance.

Work Package quality failure triggers rework by the Team Manager under MP; the PM checks acceptance only after rework passes the Product Description quality criteria.

Last updated: August 2026

The Practitioner exam rarely asks isolated definitions of Controlling a Stage and Managing Product Delivery. It tests whether you can combine them — tracing a problem from a Team Manager's workbench, through the PM's control loop, up to the Project Board's exception decision. The four worked scenarios below practise that movement.

Scenario A — A Team Manager reports an off-specification

Situation. During execute a Work Package , a Team Manager discovers that a product cannot meet a quality criterion in its Product Description: a software component's response time is 1.8 seconds against a 1.2-second criterion. The Team Manager raises an Issue (an off-specification ) and submits it in the next Checkpoint Report.

Process interplay. Under Managing Product Delivery , the Team Manager has flagged the issue and stopped trying to deliver a non-conforming product. The Issue enters the Issue Register and is examined under the capture and examine issues and risks activity of Controlling a Stage . The PM assesses the impact: is this within the Work Package tolerance, within the stage tolerance, or beyond it?

If the impact is contained within the Work Package tolerance, the PM directs corrective action (perhaps a change to the quality method, agreed with the Team Manager) and the issue is closed without escalation.

If the impact threatens the stage tolerance — for example, the rework will push the stage cost forecast beyond +3% — the PM raises an Exception Report to the Project Board.

Roles and products. Team Manager (Issue originator, MP), PM (assesses under CS, raises Exception Report), Project Board (receives Exception Report, chooses an option). Management products in play: Issue Report, Issue Register, Checkpoint Report, Exception Report, Work Package, Product Description. Note that the Team Manager does not go to the board directly — the PM is the channel.

Scenario B — Stage cost tolerance forecast breached

Situation. Two Work Packages are running late. The PM's latest forecast, produced during review stage status , shows the stage will finish 6% over cost against a +3% stage tolerance. No single issue triggered this — it is the cumulative drift from several small delays.

Process interplay. This is the canonical Exception Report trigger in Controlling a Stage . The PM raises an Exception Report to the Project Board. The report describes the cause, the forecast breach, the impact on the Business Case, and options. The Project Board then chooses between its exception options:

• Board option When used
• Give advice The PM can recover within tolerance with a course correction

Adjust tolerance The breach is acceptable given the Business Case, and the stage should continue with a new tolerance

• Instruct an Exception Plan The stage needs replanning before it can continue
• Halt the project The Business Case is no longer viable
• Premature closure The project should be closed early and its products handed over as-is

If the board instructs an Exception Plan , the PM produces it (using Managing a Stage Boundary planning activities) and submits it for approval; once approved, it replaces the affected Stage Plan and the stage continues.

Roles and products. PM (raises Exception Report under CS), Project Board (chooses option), PM again (produces Exception Plan if instructed). Management products: Exception Report, Exception Plan, updated Stage Plan, updated Business Case (if benefits are affected). The Team Managers continue executing their Work Packages under MP unless instructed otherwise — they are not paused automatically.

Scenario C — A risk materialises mid-stage

Situation. A risk recorded in the Risk Register — "key supplier may delay delivery of a hardware component" — materialises halfway through the stage. The supplier confirms a four-week slip.

Process interplay. Under Controlling a Stage , the PM captures the change in risk status and assesses the impact during capture and examine issues and risks . The Risk Register is updated: the risk moves from 'threat' to 'issue' (or a corresponding issue is raised alongside the risk). The PM evaluates whether the slip breaches the stage time tolerance. If it does, an Exception Report follows (same path as Scenario B). If the slip is within stage tolerance, the PM takes corrective action — perhaps re-sequencing other Work Packages, drawing on contingency, or negotiating a revised Work Package with the affected Team Manager under Managing Product Delivery .

Roles and products. PM (captures, assesses, decides on corrective action or escalates), Team Manager (may receive a revised Work Package or a change to a Product Description), Project Board (only if escalated). Management products: Risk Register, Issue Register (if an issue is raised), updated Work Package, Highlight Report (the materialised risk should appear in the next one), Exception Report (if tolerance is forecast to be breached).

Scenario D — Work Package quality failure

Situation. A Team Manager delivers a product to the PM under notify Work Package completion , but the acceptance check (performed by the PM or a named accepter) finds that the product fails two quality criteria in its Product Description.

Process interplay. The product is not accepted . It remains the Team Manager's responsibility and returns to the execute a Work Package activity in Managing Product Delivery for rework. The PM does not perform the rework — the PM is not the specialist. The PM's role is to confirm the failure against the Product Description, record it (an Issue or a quality record, depending on the project's quality approach), and pass it back. If the rework pushes the Work Package outside its tolerance, the Team Manager raises an Issue to the PM, and the PM may need to escalate under Controlling a Stage if the stage tolerance is threatened.

Roles and products. Team Manager (reworks under MP), PM (confirms failure, returns product, records issue), accepter named in the Work Package (performs acceptance). Management products: Product Description, Work Package, Quality Register entry, Issue Report (if tolerance impact). This scenario is a clean illustration of why the boundary between CS and MP matters: quality acceptance is a PM-side check, but quality production is a Team Manager-side responsibility.

Cross-scenario pattern

Every scenario follows the same shape: something happens at the team level, the PM assesses it under Controlling a Stage, and the PM either handles it within tolerance (corrective action, Work Package update, Issue/Risk Register update) or escalates it (Exception Report to the Project Board, which chooses an option). The Team Manager never bypasses the PM. The Project Board never receives a Checkpoint Report. Tolerances flow downward (project → stage → Work Package); issues and exceptions flow upward (Work Package → stage → project). Practitioner questions reward candidates who can trace that flow in either direction.