12.3 Stage Control & Exception Scenarios (BL4)

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:

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.