2.3 Manage by Stages & Manage by Exception

2.3 Manage by Stages & Manage by Exception

Practitioner Core Mandate: Detailed long-term planning is an illusion: the further into the future a project plan extends, the less accurate it becomes. PRINCE2 addresses this reality through two interlocking principles: Manage by Stages, which breaks the project into manageable planning horizons separated by formal governance go/no-go gates, and Manage by Exception, which establishes autonomous operational boundaries so management layers only intervene when defined performance thresholds are threatened.

---

Principle 4: Manage by Stages

The principle of Manage by Stages mandates that a project must be planned, delegated, monitored, and controlled on a stage-by-stage basis. Rather than committing resources blindly to a multi-year endeavour, the Project Board authorizes expenditure one discrete management stage at a time.

The Planning Horizon Mechanism

A core premise of PRINCE2 is the planning horizon: the limit of time into the future for which it is possible to plan with reliable accuracy.

• A high-level Project Plan outlines major milestones, total budget, and projected delivery across the entire project lifecycle.
• A detailed Stage Plan is produced only immediately prior to the commencement of that specific stage, ensuring that resource allocations, schedules, and work packages reflect real-world, current data.

PROJECT LIFECYCLE HORIZON:
[Initiation Stage] ──► [Delivery Stage 1] ──► [Delivery Stage 2] ──► [Final Delivery Stage]
       │                       │                      │                     │
       ▼                       ▼                      ▼                     ▼
[Stage Boundary Gate]   [Stage Boundary Gate]  [Stage Boundary Gate]   [Project Closure]
• Business Case Check   • Business Case Check  • Business Case Check   • Final Product Handover
• Authorize Next Plan   • Authorize Next Plan  • Authorize Next Plan   • Post-Project Benefits

Mandatory Stage Requirements

PRINCE2 establishes two non-negotiable structural rules regarding management stages:

1. A Minimum of Two Management Stages: Every PRINCE2 project must have at least two management stages:
   • The Initiation Stage: Where the Project Initiation Documentation (PID) is assembled, baseline strategies are established, and the detailed plan for Stage 2 is produced.
   • At Least One Delivery Stage: Where the actual specialist products are developed and implemented.
2. Management Stages Never Overlap: Management stages are strictly sequential. A new management stage cannot begin until the Project Board has formally evaluated the outgoing stage's performance and approved the incoming Stage Plan.

Management Stages vs. Technical Stages

Candidates on the Practitioner exam frequently confuse management stages with technical stages:

Exam Key Rule: A technical stage (such as "Software Testing" or "Site Excavation") can span across multiple management stage boundaries, or several technical sprints can occur within a single management stage. However, management stage boundaries are fixed governance gates that cannot be bypassed.

---

Principle 5: Manage by Exception

Principle 5, Manage by Exception, defines how authority is delegated from one management level to the next. The Project Board empowers the Project Manager to run the day-to-day delivery of a stage without interference, provided performance remains within agreed tolerances.

This principle eliminates micro-management: senior executives do not sit through operational status meetings, and Project Managers do not micromanage specialist engineers, as long as delivery parameters stay within predefined boundaries.

The Seven Performance Targets and Tolerances in PRINCE2 7

In PRINCE2 7, tolerances are defined across seven performance targets (expanded from six in earlier editions with the critical addition of Sustainability):

The Hierarchy of Tolerances

Tolerances cascade downwards through the management layers:

[the business layer]
         │ Sets Project-Level Tolerances
         ▼
[Project Board (Directing)]
         │ Sets Stage-Level Tolerances
         ▼
[Project Manager (Managing)]
         │ Sets Work Package-Level Tolerances
         ▼
[Team Manager (Delivering)]

1. The business layer allocates Project Tolerances to the Project Board.
2. The Project Board allocates Stage Tolerances to the Project Manager in the approved Stage Plan.
3. The Project Manager allocates Work Package Tolerances to Team Managers in approved Work Packages.

---

The Exception Escalation Workflow

Manage by Exception operates on a proactive early-warning mechanism. The trigger for escalation is not an actual breach, but a forecast breach.

[Team Manager identifies forecast Work Package tolerance breach]
         │ Raises Issue to Project Manager immediately
         ▼
[Project Manager assesses impact against Stage Tolerances]
         │ Forecast breach of Stage Tolerance confirmed?
         ├──► NO: Project Manager resolves within Stage Tolerances
         │
         └──► YES: Project Manager creates EXCEPTION REPORT
                     │ Escalates to Project Board immediately
                     ▼
         [Project Board reviews Exception Report]
                     │ Options: Request Exception Plan, Grant Concession, or Close Project
                     ▼
         [If approved: Project Manager creates EXCEPTION PLAN via SB process]
                     │
                     ▼
         [Project Board authorizes Exception Plan to replace current Stage Plan]

The Exception Report

When the Project Manager forecasts that any of the seven stage tolerances will be exceeded, the Project Manager must not attempt to "quietly fix" the issue by borrowing budget from future stages or compromising quality. The Project Manager must author an Exception Report detailing:

• The root cause of the deviation.
• The forecasted impact on cost, time, quality, scope, benefits, risk, and sustainability.
• The available recovery options and their respective trade-offs.
• The Project Manager's recommended course of action.

Project Board Decisions on an Exception Report

The Project Board evaluates the Exception Report and selects one of three formal paths:

1. Instruct an Exception Plan: Direct the Project Manager to invoke the Managing a Stage Boundary (SB) process to draft an Exception Plan that covers the remainder of the current stage. Once approved, the Exception Plan formally replaces the baseline Stage Plan.
2. Grant a Concession: Allow the product to be accepted with an off-specification variance (e.g., accepting a component that operates at 1.4 seconds instead of 1.2 seconds).
3. Direct Premature Closure: If the exception destroys the Business Case, direct the Project Manager to close the project via Closing a Project (CP).

---

PRINCE2 7 Practitioner Scenario Analysis

Scenario A: Sustainability Tolerance Breach in Hardware Procurement

A healthcare project is procuring 500 mobile diagnostic tablets in Stage 3. The approved Stage Plan specifies a Sustainability Tolerance that all purchased hardware must achieve an EPEAT Gold environmental rating and contain at least 60% post-consumer recycled plastic. Due to global supply shortages, the only available compliant tablets are backordered for six months. A secondary vendor offers tablets with an EPEAT Bronze rating and 20% recycled plastic that can ship immediately, keeping the project on schedule and on budget.

Practitioner Evaluation:

• The Project Manager cannot accept the secondary vendor's tablets simply because time and cost tolerances are preserved. Under PRINCE2 7, Sustainability is a distinct, non-negotiable performance target with its own defined tolerance.
• Purchasing the EPEAT Bronze tablets breaches the agreed sustainability tolerance.
• Mandatory Action: The Project Manager must raise an Exception Report to the Project Board outlining the breach of sustainability tolerances versus the time impact of waiting for compliant hardware. Only the Project Board has the authority to approve a concession or authorize an Exception Plan.

Scenario B: The "Quiet Fix" Anti-Pattern (PM Absorbing Schedule Overruns)

During Stage 2 of a financial portal build, development falls four weeks behind schedule due to unexpected security protocol integrations. The agreed stage time tolerance is +/- 1 week. The Project Manager instructs the delivery teams to work unpaid overtime and quietly descope secondary security reporting dashboards, planning to make up the four weeks during Stage 3 without alerting the Project Board.

Practitioner Evaluation:

• The Project Manager has committed a severe violation of Principle 5 (Manage by Exception) and Principle 4 (Manage by Stages). The moment the schedule delay was forecast to exceed the 1-week tolerance, the PM lost authority to resolve the matter autonomously.
• Descoping features without Board authorization breaches scope tolerances, and borrowing time from Stage 3 invalidates the boundary integrity of management stages.
• Mandatory Action: The Project Manager was required to submit an Exception Report immediately upon forecasting the delay. The Project Board must be informed to evaluate the trade-off between schedule extension, budget injection, or formal scope de-scoping.

---

Comparative Table: The Seven Performance Targets in Practice

---

Practitioner Exam Traps & Decision Rules

• Trap 1: Waiting for an Actual Breach to Escalate: On the Practitioner exam, questions often present a situation where a project will breach tolerance in three weeks, but currently remains within limits. The correct action is always to raise an Exception Report immediately upon forecasting the breach, never waiting for the actual breach to occur.
• Trap 2: Confusing Issue Reports with Exception Reports: An Issue Report is an operational log used by the Project Manager to record and investigate a problem, concern, or request for change. An Exception Report is a formal governance escalation document sent to the Project Board when a tolerance breach is forecast.
• Trap 3: Project Managers Approving Exception Plans: The Project Manager drafts an Exception Plan during the Managing a Stage Boundary process, but only the Project Board can authorize an Exception Plan to replace an existing Stage Plan.
• Trap 4: Overlapping Management Stages to Fast-Track Schedules: When an exam scenario suggests running Stage 3 concurrently with Stage 2 to compress timelines, this must be rejected. Management stages can never overlap, as each represents a distinct go/no-go commitment gate.