6.1 Levels of Plans, Planning Horizon & Scope

Levels of Plans, Planning Horizon & Scope in PRINCE2 7

Practitioner Core Mandate: A plan in PRINCE2 is not merely a chronological calendar or a software-generated Gantt chart; it is a vital management contract that establishes the baseline for communication, operational control, and performance measurement. PRINCE2 7 explicitly rejects the illusion that a complex multi-year project can be scheduled in minute detail upfront. Instead, through the Manage by Stages principle and the Planning Horizon concept, PRINCE2 establishes a disciplined hierarchy of plans that balances strategic long-term governance with responsive, short-term tactical control.

---

1. Purpose & Strategic Value of the Plans Practice

The purpose of the Plans practice in PRINCE2 7 is to facilitate communication and control by defining the products to be delivered, the delivery approach, the activities and dependencies, the resources required, the quality standards, the carbon and financial budgets, and the schedule of milestones necessary to satisfy the project Business Case.

Without an approved plan, project governance is impossible because:

1. No Baseline for Progress: Progress cannot be measured without a definitive baseline. One cannot state that a project is "two weeks late" or "$50,000 over budget" unless an approved plan established when deliverables were due and how much they were authorized to cost.
2. No Clear Accountability: Defined roles require explicit commitments. A plan establishes who will produce, review, approve, and fund every management and specialist product.
3. No Basis for Manage by Exception: Tolerances (for time, cost, quality, scope, benefits, risk, and sustainability) are defined directly within plans. Without tolerances tied to specific baselines, the Project Manager cannot exercise delegated autonomy, and the Project Board cannot govern by exception.

                     THE PRINCE2 PLANNING EQUATION

   ┌────────────────┐      ┌─────────────────┐      ┌─────────────────┐
   │ WHAT IS NEEDED │  ──► │ HOW & WHEN DONE │  ──► │ BASELINE CONTROL│
   │ (Products &    │      │ (Activities,    │      │ (Tolerances &   │
   │  Quality Spec) │      │  Resources,     │      │  Progress       │
   │                │      │  Dependencies)  │      │  Measurement)   │
   └────────────────┘      └─────────────────┘      └─────────────────┘

---

2. The Planning Horizon & Rolling Wave Planning

A central premise of PRINCE2 7 is that long-term detailed planning is a dangerous fallacy. In real-world projects, uncertainty increases exponentially the further one attempts to look into the future. Technological shifts, vendor availability, organizational politics, inflation, and market volatility render detailed forecasts obsolete almost as soon as they are drafted.

The Planning Horizon Defined

The Planning Horizon is the period of time over which it is realistic to forecast with accuracy and confidence.

• Within the planning horizon, the team has sufficient clarity regarding requirements, resource availability, component costs, and risks to build a detailed, daily-to-weekly operational schedule.
• Beyond the planning horizon, attempts to specify daily activities, hourly labor commitments, or exact task durations yield false precision—a fragile plan that requires endless administrative maintenance and instills a false sense of security in stakeholders.

Rolling Wave Planning in Practice

To overcome the limits of the planning horizon, PRINCE2 mandates Rolling Wave Planning, seamlessly operationalized through the Manage by Stages principle:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     ROLLING WAVE PLANNING ARCHITECTURE                      │
├─────────────────────────────────────────────────────────────────────────────┤
│ ENTIRE PROJECT LIFECYCLE: High-level Project Plan                           │
│ [Initiation Stage] ──► [Delivery Stage 1] ──► [Delivery Stage 2] ──► [Stage 3]│
│                                                                             │
│ CURRENT STAGE: Inside the Planning Horizon (Detailed Stage Plan)            │
│ ┌─────────────────────────────────────────────────────────┐                 │
│ │ Stage 1 Plan: Day-to-day activities, assigned resources,│                 │
│ │ granular work packages, weekly milestones, tolerances   │                 │
│ └─────────────────────────────────────────────────────────┘                 │
│                                                                             │
│ FUTURE STAGES: Beyond the Planning Horizon (Macro Milestones Only)          │
│                         ┌─────────────────────────────────┐                 │
│                         │ Stage 2 & 3: High-level outputs │                 │
│                         │ and target budget envelopes     │                 │
│                         └─────────────────────────────────┘                 │
└─────────────────────────────────────────────────────────────────────────────┘

1. Upfront (During Project Initiation): The Project Manager creates a high-level Project Plan covering the entire project duration. Concurrently, the Project Manager develops a granular Stage Plan solely for the immediate upcoming delivery stage.
2. At Each Stage Boundary: As the current stage nears completion, the Project Manager conducts the Managing a Stage Boundary (SB) process. With the benefit of lessons learned and recent information, the Project Manager drafts a granular Stage Plan for the next stage while updating the overall Project Plan with actual performance data and revised future projections.
3. Continuous Adjustment: The detailed planning horizon moves forward like a rolling wave, ensuring that detailed operational planning is performed only when the necessary information is reliable.

---

3. The Hierarchy of PRINCE2 Plans

PRINCE2 7 aligns its planning hierarchy directly with the three management levels of the project organization: Directing, Managing, and Delivering. In addition, it defines a contingency mechanism—the Exception Plan.

                          MANAGEMENT HIERARCHY & PLANS

   MANAGEMENT LEVEL         PRIMARY AUDIENCE         PLAN LEVEL

   Directing                Project Board            PROJECT PLAN
   (Project Executive, Users,       (Strategic Overview,     (Mandatory: Master
    Suppliers)              Investment Baseline)      Governance Baseline)
         │                                                 │
         ▼                                                 ▼
   Managing                 Project Manager          STAGE PLAN
   (Day-to-day oversight)   (Operational Steering,   (Mandatory: One per
                            Work Package Control)     Management Stage)
         │                                                 │
         ▼                                                 ▼
   Delivering               Team Manager /           TEAM PLAN
   (Specialist Production)  Specialist Teams         (Optional: Execution
                            (Task Execution)          Coordination)
   ─────────────────────────────────────────────────────────────────────────
   RECOVERY MECHANISM:      Project Board / business layer  EXCEPTION PLAN
   (Tolerance Breach)       (Emergency Baseline)     (Replaces Stage/Project)

---

4. Deep-Dive: The Core Plan Levels

4.1 The Project Plan: Strategic Governance & Investment Baseline

• Mandatory Status: Strictly mandatory for every PRINCE2 project.
• Author / Custodian: Authored by the Project Manager during the Initiating a Project (IP) process; maintained throughout the lifecycle.
• Approval Authority: The Project Board approves the initial Project Plan during Directing a Project (DP: Authorizing a Project). If the project is part of a corporate program or portfolio, the business layer may also validate it.
• Purpose & Scope: Provides the overarching business and governance baseline for the entire project from inception to closure. It outlines the major products, delivery stages, target completion dates, overall financial and sustainability budgets, major dependencies, key risks, and project-level tolerances.
• Lifecycle Maintenance: The Project Plan is not a static document. At every stage boundary (during the Managing a Stage Boundary process), the Project Manager updates the Project Plan with actual costs, carbon emissions, and time expended in the completing stage, alongside refined forecasts for remaining stages.

4.2 The Stage Plan: Tactical Operational Control for the Project Manager

• Mandatory Status: Strictly mandatory. Every management stage must have an approved Stage Plan before work in that stage can commence.
• Author / Custodian: Authored by the Project Manager.
  • The Initiation Stage Plan is produced in Starting up a Project (SU) to plan the work required to initiate the project.
  • Subsequent Delivery Stage Plans are produced in Managing a Stage Boundary (SB) towards the end of the preceding stage.
• Approval Authority: The Project Board approves each Stage Plan during Directing a Project (DP: Authorizing a Stage or Exception Plan).
• Purpose & Scope: Serves as the Project Manager's primary operational steering tool. It covers the duration of a single management stage in granular detail, mapping out every specialist product, activity, resource assignment, quality review, and daily/weekly schedule.
• Granularity & Tolerances: The Stage Plan establishes the specific stage tolerances (time, cost, quality, scope, benefits, risk, sustainability) delegated to the Project Manager by the Project Board. As long as performance forecasts remain within these tolerances, the Project Manager directs the stage autonomously.

4.3 The Team Plan: Specialist Execution Autonomy (Optional)

• Mandatory Status: Optional. PRINCE2 does not mandate Team Plans.
• Author / Custodian: Authored by the Team Manager (or specialist team leads).
• Agreement Authority: Negotiated and agreed between the Team Manager and the Project Manager during the Managing Product Delivery (MP: Accepting a Work Package) process.
• Governance Boundary Rule: The Project Board does NOT review, baseline, or approve Team Plans. In PRINCE2, the Project Board governs through the Project Manager. Demanding board-level sign-off on Team Plans breaches the principle of Defined Roles and Responsibilities and constitutes micromanagement.
• Purpose & Scope: Coordinates the day-to-day execution of specialist work within a single Work Package. Its necessity depends on the size of the project, technical complexity, geographical distribution of teams, and commercial arrangements (e.g., whether the team is an internal department or an external contracted vendor).

4.4 The Exception Plan: Restoring Governance After Tolerance Breaches

• Trigger: Prepared only when an agreed stage tolerance or project tolerance is forecast to be exceeded (or has been breached).
• The Escalation Path:

  1. Project Manager forecasts tolerance breach in Controlling a Stage (CS)
     │
     ▼
  2. Project Manager logs issue and immediately raises EXCEPTION REPORT to Project Board
     │
     ▼
  3. Project Board reviews Exception Report (Directing a Project - DP)
     │  └─ Board evaluates options and instructs PM to prepare an Exception Plan
     ▼
  4. Project Manager creates EXCEPTION PLAN in Managing a Stage Boundary (SB)
     │
     ▼
  5. Project Board reviews and authorizes EXCEPTION PLAN (DP: Authorizing a Stage/Exception Plan)
     │
     ▼
  6. EXCEPTION PLAN supersedes and replaces the failing Stage Plan (or Project Plan)
  

• Scope & Replacement: If approved, an Exception Plan completely replaces and supersedes the existing Stage Plan (or Project Plan) for the remainder of the period in question. It is not an informal amendment; it becomes the new formal baseline against which future progress and tolerances are measured.
• Approval Authority:
  • A Stage Exception Plan is approved by the Project Board.
  • A Project Exception Plan (where overall project tolerances set by the business layer are breached) must be referred by the Project Board to the business layer for ultimate approval.

---

5. Comprehensive Comparative Matrix: PRINCE2 Plan Levels

---

6. Practical Scenario Evaluations

Scenario A: The "Grand 18-Month Schedule" Fallacy

During the Initiating a Project process for the Horizon Rail Electrification project, the Project Manager builds an exhaustive 18-month scheduling file. It specifies the daily tasks, machine rental bookings, and engineer shift assignments for all four proposed delivery stages through to project closure. The Project Manager submits this 18-month file to the Project Board as the Project Plan, stating that detailed planning is now 100% complete for the entire project.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has violated the Planning Horizon concept and the principle of Manage by Stages. Attempting to schedule granular daily activities 18 months in advance represents classic "false precision."
• Impact: Environmental conditions, rail access windows, supplier delivery rates, and technical risks in Stage 1 will inevitably alter future requirements. The Project Manager will waste enormous effort continuously revising invalid future tasks.
• Correct PRINCE2 Action: The Project Board must reject the submission. The Project Manager must create a high-level Project Plan showing stage boundaries, major infrastructure milestones, overall budget envelopes, and project tolerances. Granular daily scheduling must be restricted to the Stage Plan for Stage 1.

Scenario B: Project Board Overreach on Team Plans

On the BioHealth Cloud Migration project, an external IT consultancy is engaged under a fixed-price contract to deliver a Database Optimization Work Package. During a Project Board progress meeting, the Senior User insists that the consultancy submit their internal daily sprint schedules and resource allocation rosters (Team Plan) to the Project Board for line-by-line review and approval prior to each two-week cycle.

Practitioner Evaluation:

• Governance Flaw: The Senior User is attempting to micromanage delivery and violate the principle of Defined Roles and Responsibilities.
• Impact: Demanding board approval of Team Plans destroys the delegated boundary between the Project Manager and the Team Manager, creates administrative paralysis, and exposes the client organization to contractual liability by dictating specialist supplier methods.
• Correct PRINCE2 Action: The Project Manager must advise the Senior User that Team Plans are optional delivery tools negotiated solely between the Team Manager and the Project Manager as part of Work Package agreement. The Project Board governs at the stage level using Highlight Reports and stage boundary reviews; it does not review or approve Team Plans.

Scenario C: Unilateral Tolerance Adjustments

During Stage 2 of the SolarGrid Expansion, unexpected supply chain disruptions increase solar panel costs by 15%, exceeding the approved stage cost tolerance of ±5%. Believing that savings can be achieved in Stage 3 by negotiating bulk discounts, the Project Manager modifies the Stage 2 budget baseline in the project management software, re-allocating $80,000 from the Stage 3 budget to Stage 2 without notifying the Project Board.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has committed a severe breach of the Manage by Exception principle.
• Impact: The Project Manager possesses no authority to modify approved stage budgets or reallocate capital across stage boundaries. Masking a tolerance breach deprives the Project Board of its governance mandate to evaluate continued business justification.
• Correct PRINCE2 Action: As soon as the cost overrun was forecast to exceed the ±5% stage tolerance, the Project Manager was obligated to log the issue and submit an Exception Report to the Project Board. The Project Board would then decide whether to approve an Exception Plan, inject additional funds, descope requirements, or terminate the project prematurely.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Confusing Exception Reports with Exception Plans: An Exception Report is an informational diagnostic product that alerts the Project Board that a tolerance breach is forecast, outlines options, and recommends a way forward. An Exception Plan is a complete operational replacement plan created only after the Project Board evaluates the Exception Report and explicitly instructs the Project Manager to produce it.
• Trap 2: Believing Team Plans are Mandatory: Exam questions often state that "a project cannot comply with PRINCE2 unless all Team Managers have written formal Team Plans." This is false. Team Plans are strictly optional; simple projects or co-located teams can execute Work Packages directly without formal Team Plans.
• Trap 3: Project Board Approving Team Plans: Any exam option suggesting that the Project Board, Project Executive, or Senior Supplier must "sign off" or "approve" a Team Plan is incorrect. Team Plans are agreed between the Team Manager and the Project Manager.
• Trap 4: Overwriting Plans Without Formal Exception Approval: A Project Manager cannot unilaterally "update the Stage Plan" to absorb a tolerance breach. When stage tolerances are breached, only an approved Exception Plan can replace the baseline.
• Trap 5: Assuming the Business Layer Approves All Exception Plans: The business layer only approves an Exception Plan if the Project Plan's overall project tolerances are breached. If only a Stage Plan's stage tolerances are breached, the Project Board holds the authority to approve the Stage Exception Plan.