4.4 Plans Practice & Levels of Plans

4.4 Plans Practice & Levels of Plans

Planning is the heart of effective project control. Without a clear plan, progress cannot be measured, risks cannot be anticipated, and resources cannot be allocated efficiently. The Plans Practice in PRINCE2 7 defines how plans are structured, developed, and maintained to align with the foundational principle of Manage by stages.

---

Purpose of the Plans Practice

PRINCE2 7 Definition: The purpose of the Plans practice is to establish structure, control, and baseline mechanisms to define how, when, and by whom products will be delivered and performance measured.

In PRINCE2, a plan is not merely a gantt chart or activity schedule; it is a comprehensive management document that specifies targets for all seven performance aspects: Time, Cost, Scope, Quality, Risk, Benefits, and Sustainability.

---

The Three Primary Levels of Plans

To match planning detail with management horizons, PRINCE2 establishes three primary levels of plans corresponding to the management levels within the project team.

┌──────────────────────────────────────────────────────────┐
│                     PROJECT PLAN                         │  (Level 2: Mandatory)
│   Overall view of entire project scope, cost, and time   │  Approved by Project Board
└────────────────────────────┬─────────────────────────────┘
                             │  Divided into Management Stages
┌────────────────────────────▼─────────────────────────────┐
│                     STAGE PLAN                           │  (Level 3: Mandatory)
│   Detailed plan for current management stage execution   │  Used by Project Manager
└────────────────────────────┬─────────────────────────────┘
                             │  Decomposed into Work Packages
┌────────────────────────────▼─────────────────────────────┐
│                     TEAM PLAN                            │  (Level 4: Optional)
│   Operational schedule for executing Work Packages      │  Used by Team Manager
└──────────────────────────────────────────────────────────┘

---

The Exception Plan Lifecycle

When a Stage Plan or the overall Project Plan is forecast to exceed agreed tolerances for time, cost, scope, quality, risk, or benefits, an Exception Situation occurs. The Project Manager escalates the issue to the Project Board via an Exception Report.

If the Project Board agrees that the stage or project cannot continue under the current plan, it instructs the Project Manager to produce an Exception Plan during the Managing a Stage Boundary (SB) process.

• Exception Plan Definition: A plan created to show how the project or stage will recover from a tolerance breach. It spans from the current point in time to the end of the stage (or project).
• Approval Authority:
  • If a Stage Plan breaches tolerance, the Project Board approves the Exception Plan.
  • If the overall Project Plan breaches tolerance, Corporate, Programme Management, or Customer must approve the Exception Plan.
• Baseline Replacement: Once approved, the Exception Plan replaces the existing breached Stage Plan or Project Plan to become the new official performance baseline.

Exam Tip: An Exception Plan is NOT an optional level of plan. It is a conditional plan produced only in response to a tolerance exception.

---

Management Stages vs. Technical Stages

A central concept in PRINCE2 planning is the distinction between Management Stages and Technical Stages.

Management Stages (Mandatory)

• Definition: Discrete partitions of the project lifecycle that the Project Board authorizes one at a time.
• Focus: Governance, commitment of funds, risk review, and business case re-verification.
• Requirement: Every PRINCE2 project MUST have at least two management stages: an Initiation Stage and at least one Delivery Stage.

Technical Stages (Optional / Advisory)

• Definition: Groupings of specialist work based on technical skillset or development method (e.g., Requirements Gathering, Architectural Design, Testing, Deployment).
• Focus: Technical sequence of execution.
• Relationship: Technical stages can cross management stage boundaries, or multiple technical stages can occur inside a single management stage.

---

Determining Management Stage Boundaries & Planning Horizons

The Project Manager and Executive decide how to divide a project into management stages based on four key factors:

1. Planning Horizon: How far into the future it is possible to accurately plan without making wild assumptions. Detailed planning beyond the planning horizon is inefficient.
2. Project Risk: Higher risk periods (e.g., unproven technology or complex legal negotiations) warrant shorter management stages to allow frequent Project Board reviews.
3. Financial Commitment Horizons: Aligning stage boundaries with major capital authorization decisions or vendor contract payment gates.
4. Organizational Control Points: Aligning with corporate budgeting cycles or programme review milestones.

---

Planning in Agile Environments

In agile delivery contexts, PRINCE2 planning levels seamlessly integrate with iterative techniques:

• The Project Plan defines high-level release roadmaps and overall project tolerances.
• Stage Plans align with major release cycles or fixed timeboxes (e.g., a 2-month management stage).
• Team Plans map directly to Sprint Backlogs, Iteration Plans, or Kanban flow boards managed by self-organizing delivery teams within Work Package constraints.