13.3 Managing Stage-Level Risks, Issues, and Escalations

Managing Stage-Level Risks, Issues, and Escalations in PRINCE2 7

Practitioner Core Mandate: Project delivery is never frictionless. Even the most meticulously planned management stage encounters unexpected friction: supplier insolvencies, design defects, material price volatility, extreme weather, and emerging stakeholder requirements. In PRINCE2, the mark of an effective Project Manager is not whether issues occur, but how they are captured, evaluated, and controlled. Operating under the Manage by Exception principle, the Project Manager acts as an autonomous governor within agreed tolerances—taking corrective action swiftly when within limits, but escalating with immediate transparency via an Exception Report the moment an approved boundary is forecast to be breached.

---

1. The Dynamic Risk & Issue Landscape in Delivery Stages

During a delivery stage, the Project Manager operates three interconnected governance activities within Controlling a Stage to manage uncertainty and change:

1. Capture and examine issues and risks: Systematically identifying, categorizing, and assessing events that could impact delivery.
2. Take corrective action: Formulating and executing management interventions to resolve deviations that remain within approved stage tolerances.
3. Escalate issues and risks: Formally escalating situations to the Project Board when stage tolerances are forecast to be breached.

                      STAGE-LEVEL ISSUE & RISK WORKFLOW
   
   UNEXPECTED EVENT OR NEW REQUIREMENT IDENTIFIED
   │
   ▼
   ┌─────────────────────────────────────────────────────────────┐
   │ CAPTURE & EXAMINE:                                          │
   │ • Log informally in Daily Log OR formally in Issue Register │
   │ • Assess impact on Business Case & 7 Performance Targets    │
   └──────────────────────────────┬──────────────────────────────┘
                                  │
                 Does impact exceed Stage Tolerances?
                                  │
               NO                 │                YES
        ┌─────────────────────────┴────────────────────────┐
        ▼                                                  ▼
   ┌───────────────────────────┐         ┌───────────────────────────────┐
   │ TAKE CORRECTIVE ACTION    │         │ ESCALATE TO PROJECT BOARD     │
   │ • Act autonomously        │         │ • Draft EXCEPTION REPORT      │
   │ • Adjust internal tasks   │         │ • Project Board decides under │
   │ • Update Stage Plan & Log │         │   DP: "Direct Exception Plan" │
   │ • Report in Highlight Rpt │         └───────────────────────────────┘
   └───────────────────────────┘

The Logging Architecture: Daily Log vs. Formal Registers

A common area of confusion is knowing where and when to record project information during stage delivery:

---

2. Capturing & Examining Issues: The 5-Step Control Procedure

When a formal issue arises during stage execution, the Project Manager must follow the Issue and Change Control Procedure baselined in the Change Management Approach:

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE 5-STEP ISSUE AND CHANGE CONTROL PROCEDURE                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. CAPTURE: Record in Issue Register; assign unique ID; create Issue Report.│
│ 2. ASSESS: Analyze impact on Business Case, schedule, budget, & 7 targets.  │
│ 3. PROPOSE: Identify and evaluate alternative recovery options.             │
│ 4. DECIDE: Determine course of action (PM, Change Authority, or Board).     │
│ 5. IMPLEMENT: Execute decision (corrective action or Exception Plan).       │
└─────────────────────────────────────────────────────────────────────────────┘

The Three Classifications of Issues

Every issue captured must be classified into one of three official PRINCE2 categories:

1. Request for Change (RFC): An explicit proposal to alter an approved baseline deliverable, management approach, or project requirement (e.g., the client requests an additional reporting dashboard or upgraded finishes). An RFC always seeks to add, remove, or modify baselined scope.
2. Off-Specification: A situation where a deliverable currently fails, or is forecast to fail, to satisfy its approved Product Description quality specifications (e.g., a software algorithm processes 800 transactions per second instead of the mandatory 1,000 TPS, or concrete compressive strength falls 5% below structural specification). If the product cannot be brought into compliance, a concession must be requested from the Project Board or Change Authority.
3. Problem / Concern: Any unexpected event, circumstance, or ambiguity that requires management attention but does not immediately alter baselined specifications (e.g., key specialist team members resigning, an unexpected regulatory audit, or a shipping vessel delayed by port strikes).

---

3. Impact Assessment Across the Seven Project Performance Targets

In PRINCE2 7, when examining issues and risks, the Project Manager cannot conduct a narrow evaluation focusing merely on cost and time. The assessment must systematically analyze the ripple effect across all seven project performance targets:

┌─────────────────────────────────────────────────────────────────────────────┐
│           THE SEVEN-TARGET IMPACT ASSESSMENT IN PRINCE2 7                   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. COST: Will fixing this issue require additional capital, labor, or fees? │
│ 2. TIME: Will the recovery action delay intermediate milestones or stage end?│
│ 3. QUALITY: Will the technical fix compromise performance or durability?    │
│ 4. SCOPE: Does the solution require descoping other features or adding work?│
│ 5. BENEFITS: Will delayed delivery or modified features erode business ROI? │
│ 6. RISK: What secondary threats or legal exposures are introduced?          │
│ 7. SUSTAINABILITY: Will the fix increase carbon, energy, or material waste? │
└─────────────────────────────────────────────────────────────────────────────┘

Sustainability Tolerances in PRINCE2 7

A major addition in PRINCE2 7 is the formal inclusion of Sustainability as one of the seven core project performance targets. During delivery stages, the Project Manager must track sustainability metrics with the same discipline applied to financial expenditure:

• Carbon Ceilings: Tracking greenhouse gas emissions (e.g., embodied carbon in building materials, cloud computing carbon footprints).
• Waste Diversion: Tracking demolition or manufacturing scrap sent to landfills vs. recycled.
• Energy & Resource Efficiency: Monitoring power consumption during testing or construction phases.
• Ethical Supply-Chain Metrics: Adherence to labor standards and sustainable sourcing mandates.

[!IMPORTANT] Sustainability Tolerance Breaches Require Escalation: If a delivery issue forces a team to adopt a workaround that breaches the baselined stage sustainability tolerance (e.g., switching from maritime freight to air freight, increasing carbon emissions by 40 tonnes against a ±5 tonne stage ceiling), this constitutes a formal tolerance breach! The Project Manager cannot authorize this independently; an Exception Report must be submitted to the Project Board.

---

4. Corrective Action Autonomy vs. Project Board Escalation

The cornerstone of the PRINCE2 Practitioner exam is evaluating whether a Project Manager's proposed action is legitimate under the Manage by Exception principle.

The Autonomous Authority of the Project Manager

The Project Manager has full authority to act independently during the activity Take corrective action, provided that:

• The estimated final stage outcome will remain within the approved stage tolerances across all seven targets.
• The action does not violate corporate policies, safety mandates, or statutory regulations.
• The action does not alter baselined Product Descriptions without Change Authority approval.

Examples of Autonomous Corrective Actions:

• Authorizing non-critical overtime paid from existing stage labor contingency.
• Re-sequencing internal tasks that do not impact the stage completion date or external dependencies.
• Reallocating internal specialist staff between active Work Packages.
• Drawing down on allocated Work Package tolerances to absorb minor delays.

The Limit of Autonomy: When Tolerance is Forecast to be Breached

The moment an issue or risk indicates that an approved stage tolerance is forecast to be exceeded, the Project Manager's authority to resolve the matter independently immediately terminates:

• The PM cannot unilaterally spend contingency funds beyond approved stage cost tolerances.
• The PM cannot extend the stage end date beyond approved stage time tolerances.
• The PM cannot descope mandatory deliverables or accept failing products without authorization.
• The PM must immediately escalate via an Exception Report.

Comprehensive Decision Matrix: Autonomy vs. Escalation

---

5. The Escalation Mechanism: Anatomy of an Exception Report

When a stage tolerance breach is forecast, the Project Manager executes the activity Escalate issues and risks by drafting and submitting an Exception Report.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     STRUCTURE OF AN EXCEPTION REPORT                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. EXCEPTION TITLE & REFERENCE: Stage number, date, author (PM).            │
│ 2. CAUSE OF EXCEPTION: Clear description of root cause triggering deviation.│
│ 3. CONSEQUENCE & IMPACT ASSESSMENT: Detailed analysis across 7 targets:     │
│    • Impact on Stage Plan (cost, schedule, quality, sustainability).        │
│    • Impact on Project Plan and Business Case (ROI, payback period).        │
│ 4. EVALUATED OPTIONS: Objective appraisal of viable recovery alternatives:  │
│    • Option 1: Do nothing / accept deviation (concession).                  │
│    • Option 2: Recovery action A (e.g., inject funds, crash schedule).      │
│    • Option 3: Recovery action B (e.g., descope secondary features).        │
│    • Option 4: Premature closure of the project.                            │
│ 5. RECOMMENDED OPTION: The Project Manager's recommended course of action.  │
│ 6. LESSONS LEARNED: Immediate takeaways from the exception event.           │
└─────────────────────────────────────────────────────────────────────────────┘

The Golden Exam Rule: Exception Report vs. Exception Plan

A frequent failure point on the Practitioner exam is confusing an Exception Report with an Exception Plan:

• Exception Report: Created by the Project Manager in Controlling a Stage (CS). It alerts the Project Board that an exception has occurred or is forecast, analyzes options, and recommends a solution. It is diagnostic and evaluative.
• Exception Plan: Created by the Project Manager in Managing a Stage Boundary (SB), only after the Project Board directs it under Directing a Project (DP). It is a detailed, product-based operational baseline that, once approved by the Board, supersedes and replaces the current Stage Plan.

---

6. The Change Authority and the Change Budget

To prevent the Project Board from being inundated with minor Requests for Change, PRINCE2 enables the Board to delegate change approval powers to a Change Authority.

Roles and Delegated Thresholds

• The Project Board may appoint the Project Manager, an engineering lead, or a dedicated committee as the Change Authority.
• The Board defines explicit delegated limits (e.g., the Change Authority can approve any RFC costing up to $15,000 and delaying schedule by up to 3 days, provided stage tolerances are not breached).
• Any change exceeding these delegated limits must be escalated to the full Project Board.

The Change Budget

• A Change Budget is a dedicated financial allocation established during project initiation specifically reserved to fund authorized Requests for Change and Off-Specification concessions.
• The Change Budget is not an operational contingency fund for absorbing cost overruns caused by poor estimation or planning errors. It is strictly reserved for buying new scope or paying for approved specification deviations.

---

7. Practical Practitioner Scenarios: Escalation vs. Autonomy

Scenario A: The Carbon Emission Ceiling Breach (Sustainability Tolerance)

On a sustainable commercial timber building project, a delivery stage has an agreed sustainability tolerance: total carbon emissions from material transport must not exceed 50 tonnes CO2e (±5 tonnes). Mid-stage, a major regional rail bridge collapse prevents rail transport of glulam timber beams. The only alternative is utilizing heavy diesel trucking, which will generate 78 tonnes CO2e. The PM notes that the trucking cost can be absorbed within the stage budget contingency and that delivery dates will be met. The PM signs the trucking contract and records the rail disruption in the Daily Log.

Practitioner Evaluation:

• Governance Flaw: Severe violation of the Manage by Exception principle in PRINCE2 7.
• Consequences: The PM treated sustainability as an irrelevant secondary metric, focusing solely on cost and schedule. However, in PRINCE2 7, sustainability is an equal performance target with baselined tolerances. Transport emissions of 78 tonnes represent an unauthorized 23-tonne breach over the maximum tolerance ceiling (55 tonnes).
• Correct PRINCE2 Action: The PM has zero authority to approve a course of action that breaches a baselined stage tolerance. The PM must immediately produce an Exception Report detailing the rail bridge collapse, the carbon and cost impacts of diesel trucking vs. waiting for bridge repairs, and present the options to the Project Board for executive direction.

Scenario B: The Scope Compromise Trap (Off-Specification vs. RFC)

During Stage 2 of a pharmaceutical packaging line installation, the high-speed labeling machine delivered by a German vendor operates at 450 bottles per minute, failing to meet the baselined Product Description requirement of 500 bottles per minute. The vendor offers a $20,000 discount if the client accepts the machine as-is. The PM realizes that accepting the machine and taking the discount will keep the stage within cost tolerance, so the PM agrees to the deal, updates the Stage Plan, and logs the $20,000 savings in the next Highlight Report.

Practitioner Evaluation:

• Governance Flaw: The PM has usurped the authority of the Project Board and Change Authority.
• Consequences: The delivered machine is an Off-Specification. A Project Manager has no authority to accept a non-conforming product that fails quality specifications or acceptance specifications. Slower labeling may bottleneck downstream packaging, destroying the business benefits projected in the Business Case.
• Correct PRINCE2 Action: The PM must log the non-conformance as an Off-Specification in the Issue Register. Accepting a substandard product requires a formal concession. The PM must submit an Issue Report (or Exception Report if benefits are threatened) to the Project Board or Change Authority, who alone hold the authority to grant a concession or demand vendor remediation.

Scenario C: Project Manager Exceeding Stage Cost Contingency

During civil excavation for an underground parking facility, contractors encounter unexpected toxic industrial waste. Remediation requires specialized hazardous material disposal costing $85,000. The approved stage cost tolerance is ±$25,000, and $10,000 in contingency has already been spent on pumping equipment. The PM negotiates with the disposal contractor to defer billing until the next management stage, arguing that this keeps the current stage expenditure on paper within the $25,000 tolerance window.

Practitioner Evaluation:

• Governance Flaw: Gross procedural misconduct and deliberate evasion of the Manage by Exception principle.
• Consequences: A tolerance breach is measured by committed actuals and forecasts, not accounting invoice deferrals. The project is committed to an $85,000 liability that shatters the stage tolerance. The PM's deception exposes the organization to severe financial distress.
• Correct PRINCE2 Action: The moment the hazardous waste was identified and the $85,000 cost was quoted, the stage cost tolerance was forecast to be breached. The PM must immediately raise an Exception Report to the Project Board. The Board reviews options (e.g., capping the site, seeking government remediation grants, or abandoning the project) and directs the PM accordingly.

---

8. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing the PM Can Resolve a Forecast Tolerance Breach Independently: A Project Manager can never 'self-heal' a forecast tolerance breach. Once a stage tolerance is forecast to be exceeded, autonomous authority ceases, and an Exception Report is mandatory.
• Trap 2: Submitting an Exception Report for Every Minor Issue: If an issue or variance can be absorbed within approved stage tolerances without affecting subsequent stages or the Business Case, the PM must handle it autonomously via corrective action. Escalating within-tolerance issues violates the Manage by Exception principle by wasting Project Board time.
• Trap 3: Confusing Requests for Change with Off-Specifications: An RFC requests a modification to baselined requirements (asking for something new or different). An Off-Specification documents something that was planned but is currently failing, or forecast to fail, to meet agreed criteria.
• Trap 4: Assuming the Change Authority Can Alter Project Tolerances: The Change Authority operates strictly within delegated limits and change budgets set by the Project Board. It cannot alter stage or project tolerances, nor can it override Project Board decisions.
• Trap 5: Ignoring Sustainability Tolerances During Stage Delivery: On the PRINCE2 7 exam, sustainability is not an optional corporate social responsibility checklist; it is an active performance target with strict tolerances. Treating carbon, energy, or waste breaches as minor operational details will lead to wrong exam answers.