10.1 Progress Control, Management Stages & Tolerances Across Seven Targets

Progress Control, Management Stages & Tolerances Across Seven Targets in PRINCE2 7

Practitioner Core Mandate: In PRINCE2 7, progress is not an uncoordinated collection of status meetings, timesheets, or subjective gut feelings. It is the disciplined, continuous measurement of actual product delivery against an approved baseline plan, combined with predictive forecasting to protect business justification. Through the Progress practice, PRINCE2 equips governance layers with the authority, tools, and thresholds needed to ensure the project remains viable, desirable, and achievable. Mastering how management stages are structured and how tolerances across all seven performance targets are delegated and defended is paramount for the Practitioner examination.

---

1. Purpose & Core Concepts of the Progress Practice

Every project entails uncertainty, operational friction, and shifting external conditions. Without structured progress controls, projects silently wander off course—consuming capital, burning schedules, missing quality standards, and exceeding environmental limits without executive awareness.

Official Definition of Progress

In PRINCE2 7, Progress is formally defined as:

"The measure of the development of products against the plan."

Notice the strict focus on products rather than activities. In PRINCE2, progress is never measured by how busy team members are, how many hours were logged, or how much money was spent. Progress is measured strictly by deliverables that have been completed and verified against their agreed quality specifications.

Purpose of the Progress Practice

The core purpose of the Progress practice is to:

• Monitor performance: Continuously capture and evaluate actual achievements against the approved baselines (Project Plan, Stage Plan, and Work Packages).
• Provide predictive forecasting: Project future performance, milestones, and completion dates using feed-forward controls to verify whether project objectives and business benefits remain attainable.
• Control unacceptable deviations: Provide clear governance mechanisms to manage deviations from plan through delegated tolerances and structured escalation procedures.
• Sustain business justification: Ensure the Project Board has reliable data to confirm that the project remains a worthwhile investment at every stage of its lifecycle.

                     THE PRINCE2 PROGRESS CONTROL CYCLE

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                             1. MONITOR                                  │
   │  Gather actuals: completed products, quality records, cost spend,       │
   │  schedule progress, sustainability run-rates (Checkpoints, Daily Log)   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                             2. COMPARE                                  │
   │  Evaluate actuals against baselined Stage Plan & Work Package targets   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                            3. FORECAST                                  │
   │  Feed-forward analysis: Project remaining effort, costs, completion     │
   │  dates, risk exposure, and carbon footprint to stage end                │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │
                     ┌──────────────────┴──────────────────┐
                     ▼                                     ▼
          [WITHIN TOLERANCES]                    [FORECAST BREACH]
         Project Manager continues              Raise immediate EXCEPTION
         autonomous control; issues             REPORT to Project Board
         Highlight Reports to Board             for formal adjudication

Alignment with PRINCE2 Principles

The Progress practice directly enables and operationalizes four foundational PRINCE2 principles:

1. Manage by Exception: High-level management sets delegated performance boundaries (tolerances). Lower management levels manage autonomously within those boundaries, escalating only when a tolerance breach is forecast.
2. Manage by Stages: Projects are broken into manageable, sequential management stages, preventing premature commitment of resources and providing structured decision gates.
3. Continued Business Justification: Progress data continually validates whether the expected benefits justify the operational costs, risks, and environmental impacts.
4. Focus on Products: Progress tracking evaluates product completion and quality compliance, avoiding the deceptive traps of activity-based reporting.

---

2. Management Stages: The Governance Engine of PRINCE2

A central tenet of PRINCE2 is that committing an organization's entire capital and operational resources to a multi-year endeavor upfront is irresponsible management. Instead, PRINCE2 breaks projects down into discrete management stages.

What is a Management Stage?

A management stage is a section of a project that the Project Manager is managing on behalf of the Project Board at any one time, at the end of which the Project Board wishes to review progress to date, the state of the Project Plan, the Business Case and risks, and the next Stage Plan, in order to decide whether to continue with the project.

Why Management Stages Are Mandatory

Under PRINCE2, management stages are non-negotiable. They provide essential governance safeguards:

• Controlled Commitment of Funds: The Project Board commits financial and operational resources on a stage-by-stage basis. Money is released only for the forthcoming stage.
• Go / No-Go Decision Points: At the end of each stage (the stage boundary), the Project Board formally assesses whether the Business Case remains viable before authorizing the next stage.
• Review & Realignment: Management stages provide natural opportunities to incorporate lessons learned, review team performance, assess emerging risks, and adjust the Project Plan.
• Enabling Progressive Elaboration: It is impossible to plan a complex 18-month project in granular detail on day one. Management stages allow the Project Manager to maintain a high-level Project Plan for the entire lifecycle, while creating a detailed, highly accurate Stage Plan only for the immediate next stage.

The Mandatory Minimum: At Least Two Management Stages

Every PRINCE2 project, regardless of size or simplicity, must contain a minimum of two management stages:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE MANDATORY TWO-STAGE MINIMUM                         │
├─────────────────────────────────────────────────────────────────────────────┤
│ STAGE 1: THE INITIATION STAGE                                               │
│ • Objectives: Understand what must be delivered; define strategies and      │
│   management approaches; baseline the Project Business Case; develop the    │
│   Project Plan; assemble the Project Initiation Documentation (PID).        │
│ • Focus: Rigorous planning, governance setup, and baseline definition.      │
├─────────────────────────────────────────────────────────────────────────────┤
│ STAGE 2+: THE DELIVERY STAGE(S) (AT LEAST ONE)                              │
│ • Objectives: Execute planned specialist activities; create, verify, and    │
│   deliver specialist products; transition deliverables into operations;     │
│   conduct formal project closure.                                           │
│ • Focus: Product creation, quality control, acceptance, and handover.       │
└─────────────────────────────────────────────────────────────────────────────┘

[!CRITICAL EXAM RULE] The "Single-Stage Project" Fallacy: There is no such thing as a "one-stage PRINCE2 project." Even the smallest, simplest project must have an initiation stage followed by at least one delivery stage. Running an entire project in a single stage eliminates the Project Board's baseline approval gate, violating the core principle of Manage by stages.

Management Stages vs. Technical Stages

A frequent source of exam errors is confusing management stages with technical stages (often referred to as engineering phases, technical sprints, or delivery cycles):

       MANAGEMENT STAGES (Governance Commitment Gates - Sequential & Never Overlap)
       ┌───────────────────────┬───────────────────────────┬───────────────────────┐
       │   INITIATION STAGE    │     DELIVERY STAGE 1      │   DELIVERY STAGE 2    │
       └───────────┬───────────┴─────────────┬─────────────┴───────────┬───────────┘
                   │ Stage Boundary Gate     │ Stage Boundary Gate     │ Project Closure
                   ▼                         ▼                         ▼
       TECHNICAL STAGES (Specialist Execution Streams - Can Overlap or Span Stages)
       ┌───────────────┬─────────────────────────┬─────────────────────────────────┐
       │ Analysis & UI │ Architectural Framework │ Component Build & Module Coding │
       └───────┬───────┴─────────────┬───────────┴─────────────────┬───────────────┘
               │                     │                             │
               └──────── Concurrent Systems Testing ───────────────┘

Comparative Matrix: Management Stages vs. Technical Stages

---

3. Determining the Length and Number of Management Stages

PRINCE2 does not specify an arbitrary fixed duration (e.g., "stages must be 3 months"). Instead, the Project Manager and Project Board determine the number and length of management stages based on four critical governance drivers:

┌─────────────────────────────────────────────────────────────────────────────┐
│         THE 4 STRATEGIC DRIVERS OF MANAGEMENT STAGE ARCHITECTURE            │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. RISK PROFILE                                                             │
│ • High risk / technical novelty ──► Shorter stages, more frequent review    │
│ • Low risk / repetitive work    ──► Longer stages, fewer governance gates   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. PLANNING HORIZON                                                         │
│ • The temporal window within which the PM can accurately forecast effort,   │
│   resources, costs, and dependencies without resorting to guesswork.        │
│ • Stage length should never exceed the Project Manager's planning horizon.  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. ORGANIZATIONAL BUDGETING & CORPORATE CYCLES                              │
│ • Aligning stage boundaries with corporate fiscal quarters, financial       │
│   year-ends, capital investment tranches, or parent program reviews.        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. KEY DELIVERY DECISION POINTS                                             │
│ • Natural decision gates occurring after major specialist milestones:       │
│   e.g., after building architectural proof-of-concept; after obtaining      │
│   statutory environmental permits; before signing massive supplier orders.  │
└─────────────────────────────────────────────────────────────────────────────┘

Detailed Analysis of the Four Drivers

Driver 1: Project Risk Profile

The level of uncertainty and exposure dictates how tightly the Project Board must hold the reins. In high-risk environments—such as developing unproven nanotechnology or constructing a subsea pipeline—the Project Board will mandate shorter stages (e.g., 4 to 8 weeks). This restricts the financial capital exposed to loss and ensures frequent Go/No-Go checkpoints. Conversely, in low-risk, standardized rollouts, longer stages (e.g., 6 to 12 months) reduce administrative governance overhead.

Driver 2: The Planning Horizon

The planning horizon represents how far ahead the Project Manager can forecast with confidence. In fast-moving IT or market-driven projects, forecasting accurately beyond 8 to 12 weeks is virtually impossible due to external volatility. Structuring a management stage to last 9 months when the planning horizon is only 2 months forces the PM to base the Stage Plan on speculative guesses. The length of a management stage should not extend beyond the Project Manager's planning horizon.

Driver 3: Organizational Budgeting & Business-Layer Gates

Projects do not operate in a corporate vacuum. Organizations release capital based on fiscal quarters, annual budgeting rounds, or portfolio investment gates. Aligning stage boundaries with corporate capital tranches ensures that the Project Board has verified business justification and accurate actual costs immediately prior to requesting corporate funding refreshes.

Driver 4: Key Delivery Decision Points

Stage boundaries should coincide with major commitment crossroads. For example, in pharmaceutical development, a natural stage boundary occurs after Phase II Clinical Efficacy Trials. At this point, the Project Board reviews trial data: if the drug is ineffective, the project is terminated immediately, saving the organization tens of millions of dollars that would otherwise be wasted on Phase III Large-Scale Trials.

---

4. Tolerances Across All Seven Performance Targets in PRINCE2 7

To operationalize Manage by exception, every management layer must have clear, quantifiable performance boundaries within which it is empowered to work. In PRINCE2, these boundaries are called tolerances.

What is Tolerance?

Tolerance is the permissible deviation above and below an agreed plan's target without requiring that deviation to be escalated to the next higher level of management.

If a project or stage performs within its agreed tolerances, the Project Manager retains full operational authority. The moment any target is forecast to exceed its tolerance, autonomous authority ceases, and an immediate escalation must take place.

The Seven Project Performance Targets

PRINCE2 7 expands the traditional six performance targets by integrating Sustainability as a fully fledged, seventh performance target alongside Cost, Time, Quality, Scope, Benefits, and Risk:

┌─────────────────────────────────────────────────────────────────────────────┐
│            THE SEVEN PROJECT PERFORMANCE TARGETS IN PRINCE2 7               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. COST            Allowable budget variance (+ / - financial currency)     │
│ 2. TIME            Allowable schedule variance (+ / - days, weeks, months)  │
│ 3. QUALITY         Allowable performance attributes (+ / - technical specs) │
│ 4. SCOPE           Permissible variation in deliverables (MoSCoW criteria)  │
│ 5. BENEFITS        Allowable range in realized business value (+ / - ROI)   │
│ 6. RISK            Allowable ceiling on aggregated risk exposure (£ / $)    │
│ 7. SUSTAINABILITY  Allowable variance in carbon, energy, waste, materials   │
└─────────────────────────────────────────────────────────────────────────────┘

Comprehensive Breakdown of the Seven Tolerances

Table 11.1 of the manual maps each tolerance type to the plan or baseline product that carries it at each of four levels. Learn the left-hand columns, because matching questions ask where a given tolerance is recorded.

* Quality tolerances are not summarily defined at stage or work package level; they are defined per product description within the scope of the plan.

Two patterns fall out of the table and are worth memorizing. Benefits, sustainability, and risk tolerances start in the business case, not the project plan — they are justification limits, not delivery limits. Time, cost, and scope start in the project plan. And sustainability is the only target that appears at all four levels.

In-Depth Focus: The 7th Aspect — Sustainability Tolerance

In PRINCE2 7, sustainability is not an informal corporate social responsibility aspiration; it is an enforceable contractual baseline. Sustainability tolerances define the allowable boundaries of environmental and societal impact:

• Embodied & Operational Carbon: Caps on carbon emissions generated during manufacturing, construction, logistics, and subsequent operational usage.
• Energy Efficiency: Maximum allowable kilowatt-hour consumption or minimum energy ratings.
• Resource Circularity: Minimum percentage of recycled, reused, or certified sustainable raw materials.
• Waste Diversion: Mandatory thresholds for diverting construction and demolition waste away from landfills toward recycling facilities.

[!CRITICAL EXAM RULE] Sustainability Breaches Are Stage Exceptions: If an engineering team substitutes a cheaper component that saves $15,000 in cost (well within cost tolerance) but emits an extra 25 metric tons of carbon, pushing the stage carbon footprint beyond its agreed +10 MT sustainability tolerance, this is an immediate stage exception. The Project Manager has zero authority to accept this trade-off autonomously and must raise an Exception Report to the Project Board.

---

5. Allocation of Tolerances Across the Four Organizational Layers

PRINCE2 enforces strict governance boundaries. Tolerances are not created out of thin air; they are cascaded downwards through the four levels of management, establishing an unbroken chain of accountability.

                          THE 4-LEVEL TOLERANCE HIERARCHY

   ┌─────────────────────────────────────────────────────────────────────────┐
   │ LEVEL 1: CORPORATE, PROGRAMME, OR PORTFOLIO MANAGEMENT                  │
   │ • Sets overall PROJECT TOLERANCES for the Project Board                 │
   │ • Defines overall boundaries for capital, schedule, benefits, & carbon  │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │ Cascades Project Tolerances
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ LEVEL 2: DIRECTING (PROJECT BOARD)                                      │
   │ • Receives Project Tolerances; operates within them                     │
   │ • Sets and allocates STAGE TOLERANCES for the Project Manager           │
   │ • Escalates to the business layer if project tolerance is forecast to breach     │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │ Cascades Stage Tolerances
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ LEVEL 3: MANAGING (PROJECT MANAGER)                                     │
   │ • Receives Stage Tolerances; manages stage autonomously within them     │
   │ • Sets and allocates WORK PACKAGE TOLERANCES for Team Managers          │
   │ • Escalates to Project Board if Stage Tolerance is forecast to breach   │
   └────────────────────────────────────┬────────────────────────────────────┘
                                        │ Cascades Work Package Tolerances
                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ LEVEL 4: DELIVERING (TEAM MANAGER)                                      │
   │ • Receives Work Package Tolerances; delivers products within them       │
   │ • Escalates to Project Manager if WP Tolerance is forecast to breach    │
   └─────────────────────────────────────────────────────────────────────────┘

The Mechanics of Tolerance Allocation

1. The business layer to Project Board:
   • the business layer establishes Project Tolerances when chartering the project and baselining the Project Initiation Documentation (PID).
   • If the project as a whole is forecast to exceed its cost budget, project completion date, minimum benefits threshold, or carbon ceiling, the Project Board cannot fix this internally—it must refer to the business layer.
2. Project Board to Project Manager:
   • When the Project Board authorizes a Stage Plan (in the Directing a Project process), it allocates Stage Tolerances to the Project Manager.
   • Stage tolerances are carved out of the overall project tolerances. The Project Board retains a strategic buffer at the project level to handle unforeseen systemic risks.
3. Project Manager to Team Manager:
   • When the Project Manager issues a Work Package (in the Controlling a Stage process), the PM sets explicit Work Package Tolerances (typically time and cost, but also quality specifications and sustainability standards).
   • The sum of Work Package tolerances should not consume the entire stage tolerance, allowing the Project Manager an operational contingency reserve.

The Golden Escalation Rule

Delegation flows downwards; escalation flows upwards:

• If a Team Manager forecasts that a Work Package will breach its time or cost tolerance, the Team Manager must notify the Project Manager immediately by raising a team issue or Work Package exception.
• The Project Manager evaluates whether the Work Package variance can be absorbed within the remaining stage tolerance buffer. If the stage tolerance itself is threatened, the PM must immediately raise an Exception Report to the Project Board.
• Under no circumstances may a Team Manager escalate directly to the Project Board, nor may a Project Manager grant themselves additional stage tolerance.

---

6. Practical Scenario Evaluations

Scenario A: Conflating Technical Phases with Management Stages

An aerospace company is designing a high-altitude surveillance drone. The project involves two distinct technical streams: aerodynamic airframe fabrication and autonomous navigation software. The engineering director insists that because the software team uses two-week agile iterations and the airframe team uses six-month manufacturing cycles, the project should run two separate, concurrent management stages—one for software and one for hardware.

Practitioner Evaluation:

• Governance Flaw: The engineering director has conflated technical stages with management stages.
• PRINCE2 Governance Rule: Management stages never overlap. They are enterprise governance commitment gates for the Project Board. Having concurrent management stages means having multiple simultaneous Stage Plans, fragmented Project Board reviews, and chaotic financial authorizations.
• Correct PRINCE2 Action: The project must be structured into sequential management stages (e.g., Initiation Stage, Prototyping Stage, Testing & Integration Stage, Operational Handover Stage). Within any given delivery stage, both the software team (using agile sprints) and the hardware team (using manufacturing workflows) execute their specialist technical activities concurrently under separate Work Packages managed by the Project Manager.

Scenario B: The Trade-Off that Breached Sustainability Tolerance

During a university hospital construction project, the heating and cooling subsystem is running two weeks behind schedule. The mechanical contractor proposes switching from custom low-carbon pre-cast geothermal piping to off-the-shelf standard polymer piping. The substitution saves $25,000 in labor and recovers the two-week schedule delay. Both cost and schedule remain well within approved stage tolerances. However, the polymer piping increases the stage carbon footprint by 35 metric tons CO2e, whereas the agreed stage sustainability tolerance allows a maximum increase of only +5 metric tons CO2e. The Project Manager signs off on the change, believing that staying on time and under budget justifies the carbon increase.

Practitioner Evaluation:

• Governance Flaw: The Project Manager has violated the Manage by exception principle by ignoring Sustainability tolerance.
• Impact: In PRINCE2 7, Sustainability is a co-equal 7th performance target. Tolerances on sustainability are just as binding as tolerances on time and cost. A favorable variance in cost cannot be used autonomously by the PM to compensate for a breach of sustainability tolerance.
• Correct PRINCE2 Action: Because the substitution is forecast to breach stage sustainability tolerance (+35 MT vs. +5 MT allowable), the PM has zero authority to approve it. The PM must immediately log an issue and raise an Exception Report to the Project Board, outlining the trade-off options and allowing the executive board to decide whether to authorize the carbon increase, grant a tolerance uplift, or maintain the schedule delay.

Scenario C: Team Manager Bypassing Governance Levels

On a commercial financial software upgrade, a Team Manager discovers that database data cleansing is taking longer than expected. The Work Package had an agreed time tolerance of ±2 days. The Team Manager calculates that data cleansing will finish 6 days late. Believing that the Project Manager is overly strict, the Team Manager contacts the Senior Supplier on the Project Board directly during an informal lunch and obtains verbal approval for a 6-day extension, noting that the overall stage has 3 weeks of total schedule float.

Practitioner Evaluation:

• Governance Flaw: Total breakdown of the 4-level governance hierarchy and reporting lines.
• Impact: A Team Manager reports solely to the Project Manager and operates strictly within Work Package tolerances. Individual Project Board members have no authority to give ad hoc, verbal permissions to delivery teams.
• Correct PRINCE2 Action: The Team Manager must formally notify the Project Manager that the Work Package tolerance will be breached. The Project Manager assesses the 6-day delay against the overall Stage Plan. Because 3 weeks of stage buffer exist, the PM can accommodate the delay within stage tolerances by adjusting subsequent Work Package schedules, re-issuing an updated Work Package to the Team Manager without requiring an Exception Report to the Project Board.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing a Project Can Have Only One Stage: A project must have at least two management stages: initiation and at least one delivery stage. Questions suggesting that a small project can combine initiation and delivery into a single stage are always wrong.
• Trap 2: Assuming Technical Stages Dictate Management Stage Boundaries: Management stages are driven by risk, planning horizons, corporate budget gates, and major Go/No-Go decision points. Technical workflows fit inside management stages, not the other way around.
• Trap 3: Overlooking Sustainability as a Binding Tolerance: In PRINCE2 7, sustainability is not an optional ethical preference. It has baselines, measurable metrics (carbon, energy, circularity), and formal tolerances. Exceeding a sustainability ceiling is an exception requiring an Exception Report.
• Trap 4: Conflating Zero Tolerance with Infinite Tolerance: If the Project Board specifies 'zero tolerance' for a target (e.g., zero cost tolerance), the Project Manager must escalate if spending exceeds the plan by even a single dollar.
• Trap 5: Assuming the Project Manager Allocates All Stage Tolerance to Work Packages: A competent Project Manager always retains an operational contingency buffer. Allocating 100% of stage tolerances across Work Packages leaves the PM with zero margin to absorb inter-package delays or minor friction.