12.3 Creating Stage Plans and Exception Plans

Creating Stage Plans and Exception Plans in PRINCE2 7

Practitioner Core Mandate: In an ideal world, projects would execute flawlessly according to their initial baselines. In reality, unexpected site conditions, currency devaluations, technological barriers, and supply chain bankruptcies regularly threaten delivery. PRINCE2 does not pretend that plans never fail. Through the Manage by Exception principle, the method provides an orderly, disciplined mechanism for responding to severe deviations. When an approved tolerance is breached, the project does not descend into chaos; instead, the Project Board directs the creation of an Exception Plan within Managing a Stage Boundary (SB) to reset the project baseline.

---

1. The Mechanics and Governance Lifecycle of an Exception

To master the Practitioner exam, candidates must understand the precise end-to-end lifecycle of an exception across the PRINCE2 process model. An exception is not handled within a single process—it flows across three interconnected processes: Controlling a Stage (CS), Directing a Project (DP), and Managing a Stage Boundary (SB).

                      THE EXCEPTION LIFECYCLE WORKFLOW

   1. CONTROLLING A STAGE (CS)                  2. DIRECTING A PROJECT (DP)
   ┌───────────────────────────────┐            ┌───────────────────────────────┐
   │ Project Manager tracks targets│            │ Project Board reviews         │
   │ & forecasts tolerance breach  │───────────►│ Exception Report & weighs     │
   │ ──► Creates EXCEPTION REPORT  │            │ recovery options              │
   └───────────────────────────────┘            └───────────────┬───────────────┘
                                                                │ Board directs PM:
                                                                │ "Produce Exception Plan"
                                                                ▼
   4. DIRECTING A PROJECT (DP)                  3. MANAGING A STAGE BOUNDARY (SB)
   ┌───────────────────────────────┐            ┌───────────────────────────────┐
   │ Project Board reviews &       │            │ Project Manager executes SB:  │
   │ AUTHORIZES Exception Plan     │◄───────────│ • Uses Product-Based Planning │
   │ (Re-baselines stage tolerances│            │ • Produces EXCEPTION PLAN     │
   │  and replaces old Stage Plan) │            │ • Updates Business Case & Plan│
   └───────────────┬───────────────┘            └───────────────────────────────┘
                   │
                   ▼
   5. CONTROLLING A STAGE (CS)
   ┌───────────────────────────────┐
   │ PM authorizes new Work                                                     │
   │ Packages under Exception Plan                                              │
   └───────────────────────────────┘

Step-by-Step Exception Mechanics:

1. Detection & Escalation in CS: While monitoring stage progress against the seven performance targets in Controlling a Stage, the Project Manager realizes that an approved stage tolerance (e.g., cost, time, quality, scope, benefits, risk, or sustainability) is forecast to be exceeded. The PM has zero authority to resolve this breach independently. The PM immediately drafts an Exception Report detailing the root cause, business impact, evaluated recovery options, and a recommended course of action, and submits it to the Project Board.
2. Board Deliberation in DP: Under Directing a Project (activity: Give ongoing direction), the Project Board convenes to evaluate the Exception Report. The Board can: direct premature closure, instruct a workaround, or agree with the PM's recommendation and direct: "Produce an Exception Plan."
3. Plan Creation in SB: When directed by the Board, the Project Manager invokes the Managing a Stage Boundary (SB) process. Within SB, the PM creates the Exception Plan, updates the Project Plan, recalculates the Business Case, and updates the Risk Register and Issue Register.
4. Board Authorization in DP: The PM submits the Exception Plan package to the Project Board. Under Directing a Project (activity: Authorize a Stage or Exception Plan), the Board reviews the plan. If satisfied, the Board formally authorizes the Exception Plan.
5. Resuming Delivery in CS: Once authorized, the Exception Plan completely supersedes the old Stage Plan. The Project Manager returns to Controlling a Stage, authorizing Work Packages under the newly established baseline.

Vital Definitional Distinction: Exception Report vs. Exception Plan

A common exam failure point is confusing an Exception Report with an Exception Plan:

• Exception Report: A diagnostic, evaluative management document created in Controlling a Stage (CS) that alerts the Project Board that a tolerance breach is forecast, outlines options, and recommends a solution. It is not a plan; it contains no detailed schedule, no Work Packages, and no resource allocations.
• Exception Plan: An operational baseline document created in Managing a Stage Boundary (SB) that details the exact activities, products, resources, schedules, and costs required to recover from the exception. Once approved, it replaces the current plan.

---

2. Developing an Exception Plan Using Product-Based Planning

An Exception Plan is not an informal memo or high-level slide deck. It is a full-fledged, rigorous PRINCE2 plan built using the Product-Based Planning technique.

Applying Product-Based Planning to an Exception:

1. Identify Changed and New Products: The PM determines which deliverables scheduled in the original Stage Plan are impacted. Some products may be descoped; others may require technical modification or rework. Entirely new recovery products may be needed (e.g., replacement hardware, structural shoring, remedial software scripts).
2. Update the Product Breakdown Structure (PBS): The PBS is restructured to reflect the revised deliverables.
3. Create or Revise Product Descriptions: Detailed Product Descriptions must be drafted for any new products or updated for modified deliverables, establishing explicit quality specifications and acceptance methods.
4. Reconfigure the Product Flow Diagram (PFD): The sequence and dependencies of remaining deliverables are remapped.
5. Estimate & Schedule: Work effort, durations, specialist team allocations, and financial expenditures are quantified, establishing a new critical path.

Scope and Planning Horizon of an Exception Plan

A critical technical question on the Practitioner exam is: What time period does an Exception Plan cover?

                  THE PLANNING HORIZON OF AN EXCEPTION PLAN

   STAGE COMMENCEMENT         EXCEPTION OCCURS             SCHEDULED STAGE END
   │                                 │                                      │
   ├─── COMPLETED PRODUCTS ──────────┼─── UNFINISHED & REWORK ──────┤
   │    (Kept as historical actuals) │    (Discarded from baseline)         │
   │                                 │                                      │
   │                                 ▼                              ▼
   │                            ┌───────────────────────────────────────────┐
   │                            │       THE EXCEPTION PLAN COVERS:          │
   │                            │ • From the present point in time to the   │
   │                            │   end of the current management stage     │
   │                            │ • Incorporates all recovery actions,      │
   │                            │   rework, and remaining stage deliverables│
   │                            └───────────────────────────────────────────┘

• An Exception Plan does not replan the work that has already been successfully delivered and accepted earlier in the stage; those completed deliverables remain locked as historical actuals.
• An Exception Plan does not only cover the specific delayed tasks. It replans the entire remaining duration of the management stage, starting from the current moment in time through to the end of the stage. This ensures that all interrelated tasks, resource dependencies, and stage tolerances form a coherent, integrated operational baseline.

---

3. Replacing Baselined Plans and Re-Baselining Tolerances

The Act of Supersession

When the Project Board authorizes an Exception Plan, the existing baselined Stage Plan is formally superseded and retired:

• The old Stage Plan is archived for audit purposes and lessons learned analysis.
• The Exception Plan becomes the new, active operational baseline for the stage.
• The Project Manager now measures all ongoing progress and variance in Controlling a Stage against the targets set in the Exception Plan.

Re-Baselining Tolerances Across the Seven Targets

An exception occurs because original stage tolerances were inadequate to absorb operational reality. Therefore, authorizing an Exception Plan requires re-baselining tolerances:

• The Project Board establishes new, explicit tolerances for the Exception Plan across the seven performance targets (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability).
• For example, if a stage had a budget of $500k with ±$25k tolerance, and the Exception Plan budgets $620k to overcome technical failures, the Board authorizes the new baseline of $620k and sets a new tolerance window (e.g., ±$20k).
• The Project Manager's autonomous delegation is reset within these new tolerance boundaries.

---

4. Comprehensive Comparative Matrix: Regular Stage Plan vs. Exception Plan

Understanding the nuanced differences between a regular Stage Plan and an Exception Plan is essential for Practitioner scenario analysis:

---

5. Project-Level vs. Stage-Level Exceptions: Escalation Boundaries

A critical governance rule governs the authority limits of the Project Board when dealing with exceptions:

                     THE EXCEPTION ESCALATION HIERARCHY

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                CORPORATE / PROGRAMME MANAGEMENT / CUSTOMER              │
   │ • Sets overall PROJECT TOLERANCES across all 7 targets                  │
   │ • Owns project-level investment; alone can authorize project breaches   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        ▲
                                        │ Escalation if PROJECT tolerance breached
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                             PROJECT BOARD                               │
   │ • Sets STAGE TOLERANCES for the Project Manager                         │
   │ • CAN approve Stage-level Exception Plans (within Project tolerances)   │
   │ • CANNOT approve Exception Plans that breach Project tolerances!        │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        ▲
                                        │ Escalation via EXCEPTION REPORT
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                            PROJECT MANAGER                              │
   │ • Operates within agreed Stage Tolerances in Controlling a Stage        │
   │ • CANNOT resolve tolerance breaches independently                       │
   │ • Prepares Exception Plan in SB when directed by Project Board          │
   └─────────────────────────────────────────────────────────────────────────┘

Stage-Level Exception (Within Project Board Remit)

• Occurs when a stage is forecast to breach its approved stage tolerances, but the overall project-level tolerances set by the business layer remain protected.
• Authority: The Project Board possesses full authority to review and approve the Exception Plan. The Board can commit additional contingency funds or approve schedule adjustments as long as the project as a whole stays within its corporate parameters.

Project-Level Exception (Exceeding Project Board Remit)

• Occurs when recovering from the stage variance requires so much additional time, money, or scope reduction that the overall project tolerances (or Project Product Description acceptance criteria) will be breached.
• The Golden Governance Rule: The Project Board cannot approve a project-level Exception Plan on its own authority. The Project Board must escalate the Exception Plan to the business layer (commissioning).
• Only corporate/programme management has the organizational authority to inject additional enterprise capital, extend the overall project delivery deadline, adjust strategic benefits expectations, or terminate the project.

---

6. Updating the Business Case, Risk Register & Baselines During an Exception

Producing an Exception Plan is never an isolated technical scheduling exercise. The Project Manager must simultaneously update the broader governance package in Managing a Stage Boundary:

6.1 Recalculating the Business Case

When a major exception occurs, project costs typically rise and delivery dates slip. The PM must re-run the financial models:

• Does the increased expenditure still yield an acceptable Return on Investment (ROI)?
• Will delayed delivery cause market benefits to be missed (e.g., missing a holiday retail launch or regulatory compliance window)?
• Do projected business benefits still exceed the revised total project costs?
• If business justification has evaporated, the PM must clearly state this in the documentation, and the Project Board must consider terminating the project.

6.2 Re-evaluating the Risk Register

Corrective recovery actions inherently generate secondary risks:

• If the Exception Plan proposes crashing the schedule by having teams work 16-hour shifts, what is the secondary risk of increased defect rates or safety violations?
• If the Exception Plan replaces an insolvent supplier with an alternative vendor, what are the technical integration and contractual risks?
• The PM must identify, score, and log all new secondary risks in the Risk Register, ensuring that the total risk exposure of the recovery plan is transparent to the Project Board.

6.3 Updating the Project Plan

The PM must feed the revised timeline and financial figures from the Exception Plan into the master Project Plan, illustrating the ripple effect on subsequent stages and final milestone delivery.

---

7. Practical Scenario Evaluations

Scenario A: The "Self-Healing" Project Manager Trap

During Stage 2 of a pharmaceutical laboratory construction, the civil contractor encounters unexpected subterranean bedrock, delaying foundation excavation by 4 weeks against a stage time tolerance of ±1 week. The Project Manager realizes that by hiring specialized thermal drilling equipment costing $40,000, the delay can be compressed to 10 days. Because the stage budget has $50,000 in unspent contingency, the PM immediately signs the equipment contract, updates the Stage Plan on their desktop, and instructs the team to proceed, planning to explain the success in the next routine Highlight Report.

Practitioner Evaluation:

• Governance Flaw: Total violation of the Manage by Exception principle. The PM has committed a severe governance breach by attempting to 'self-heal' an escalated tolerance breach.
• Breach of Authority: The moment bedrock was encountered and a 4-week delay was forecast, the stage time tolerance was breached. At that exact moment, the PM's delegated authority to manage the stage ceased. The PM had an absolute duty to raise an Exception Report to the Project Board.
• Consequences: The PM unauthorizedly spent $40,000 and implemented an unapproved plan. If the thermal drilling damages surrounding utility conduits, the PM is personally liable for unauthorized expenditure and governance failure.
• Correct PRINCE2 Action: The PM must submit an Exception Report to the Project Board detailing the bedrock discovery, outlining options (including the $40,000 thermal drilling option), and requesting direction. Only if the Project Board directs the creation of an Exception Plan—and formally approves that plan under Directing a Project—can the PM execute the recovery work.

Scenario B: Project Board Rejecting an Exception Plan

On an enterprise ERP deployment, data migration failures in Stage 3 threaten to delay go-live by 3 months, breaching stage time tolerance. The Project Board directs the PM to produce an Exception Plan. In Managing a Stage Boundary, the PM drafts an Exception Plan that recovers 1 month of schedule but requires an additional $350,000 to hire external database consultants. During the End Stage Assessment under Directing a Project, the Senior User states that delaying go-live by even 2 months will disrupt fiscal year-end accounting, and the Project Executive confirms that the enterprise has zero budget reserves. The Project Board votes unanimously to reject the Exception Plan.

Practitioner Evaluation:

• Governance Action: The Project Board is exercising its legitimate governance accountability under Continued Business Justification.
• Consequences: The Project Board is under no obligation to rubber-stamp an Exception Plan. When an exception cannot be resolved without destroying business viability or exceeding corporate constraints, continuing delivery is irresponsible.
• Correct PRINCE2 Action: The Project Board instructs the Project Manager to initiate the Closing a Project (CP) process to effect premature closure. The PM must stop all delivery work, preserve existing code assets, conduct formal handover, compile the End Project Report documenting why the project failed, and archive records to capture organizational lessons.

Scenario C: Corporate Escalation for a Project-Level Tolerance Breach

A municipal transit agency is building a light-rail line. During Stage 4 (tunnel boring), an underground cavern collapses, destroying the tunneling shield. The PM creates an Exception Plan in SB showing that procuring a replacement shield and stabilizing the cavern will cost $45 million and add 14 months to the project. The overall project-level tolerances approved by City Council are $15 million and 6 months. The Project Board convenes and the Project Executive suggests approving the Exception Plan immediately so work can resume.

Practitioner Evaluation:

• Governance Flaw: The Project Board is attempting to exceed its delegated constitutional authority.
• Remit Boundary: The Project Board only holds delegated authority within the project tolerances granted by City Council (the business layer). Because the Exception Plan breaches project-level tolerances ($45M vs. $15M cap; 14 months vs. 6 months cap), the Project Board has zero legal or procedural authority to authorize it.
• Correct PRINCE2 Action: The Project Board must endorse the Exception Plan and formally escalate it to City Council / the business layer for decision. City Council alone can decide whether to appropriate municipal tax reserves, solicit federal grants, descope stations, or terminate the light-rail project.

---

8. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing the PM Creates an Exception Plan Immediately in Controlling a Stage: A Project Manager never creates an Exception Plan in Controlling a Stage. In CS, the PM creates an Exception Report. The Exception Plan is created only after the Project Board directs it, and it is produced within Managing a Stage Boundary (SB).
• Trap 2: Assuming the Project Manager Can Authorize an Exception Plan: A Project Manager has zero authority to approve or adopt an Exception Plan. Under the Manage by Exception principle, only the Project Board (or the business layer for project-level breaches) can authorize an Exception Plan.
• Trap 3: Believing an Exception Plan Only Re-plans the Problem Deliverable: An Exception Plan does not simply patch a single delayed task. It replans the entire remaining period of the management stage, integrating all deliverables, resource allocations, and new tolerances.
• Trap 4: Forgetting that Exception Plans Use Product-Based Planning: Exception Plans are not informal memos. They require the full product-based planning rigor: PBS, PFD, Product Descriptions, and quality specifications.
• Trap 5: Confusing Stage-Level with Project-Level Tolerance Breaches: If an exam question mentions that an exception breaches the project's overall budget or delivery date, the Project Board cannot approve it. The correct answer will involve escalating the Exception Plan to the business layer.