2.3 Performance Targets, Tolerances & Project Context

PRINCE2 Practitioner Version 7

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique

2 PRINCE2 7 Method Overview

2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context

3 PRINCE2 Principles (1–4)

3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages

4 PRINCE2 Principles (5–7) & Applying Principles

4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context

5 People Management in Projects

5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management

6 Practices Overview & Business Case

6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios

7 Practices: Organising & Plans

7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring

8 Practices: Quality & Risk

8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application

9 Practices: Issues

9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment

10 Practices: Progress, Sustainability & Application

10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)

11 Processes: Model, Starting, Directing & Initiating

11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project

12 Processes: Controlling a Stage & Product Delivery

12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle

13 Processes: Stage Boundary, Closing & Tailoring

13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)

14 Tailoring, Management Products & Exam Technique

14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps

2.3 Performance Targets, Tolerances & Project Context

Key Takeaways Explain This Topic AI

PRINCE2 7 defines seven project performance targets: benefits, cost, time, quality, scope, risk, and sustainability.

Tolerances are the permissible deviation set for each target; breaching a tolerance triggers an exception escalation to the level above.

Three tolerance levels exist: project (set by programme/corporate), stage (set by the Project Board), and team (set by the Project Manager in a Work Package).

Manage by exception means no escalation is needed while forecasts stay within tolerance; an exception is raised only when a tolerance is forecast to be breached.

Project context — commercial, programme, or internal — drives how the method is tailored to scale, complexity, risk, and organisation.

Last updated: August 2026

The Seven Project Performance Targets

Every PRINCE2 project is accountable for delivering against seven performance targets . v6 had six; v7 adds sustainability.

Target Question it answers v7 status
Benefits Will the project deliver the expected value? Carried over
Cost Will it stay within budget? Carried over
Time Will it finish on schedule? Carried over
Quality Will the outputs meet acceptance criteria? Carried over
Scope Will it deliver what was agreed — no more, no less? Carried over
Risk Are threats and opportunities being managed within appetite? Carried over
Sustainability Are environmental, social, and economic impacts being managed? New in v7

These targets are not independent. A decision to cut cost often affects scope, quality, benefits, and sustainability. The Project Board and Project Manager weigh trade-offs against all seven, not against cost alone.

Tolerances

A tolerance is the permissible deviation for each performance target before escalation is required. Tolerances exist for every target — cost can vary ±10%, time can slip ±5 days, scope can flex within a named boundary, and so on. Crucially, tolerances are set above the level they govern, so that authority and accountability stay aligned.

Three tolerance levels

Level Who sets it What it bounds Typical example

Project tolerance Programme or corporate The whole project's targets Cost ±10%, time ±1 month, scope within agreed product breakdown

Stage tolerance Project Board A single management stage Stage cost ±5%, stage time ±2 weeks

Team tolerance Project Manager (in a Work Package) A team's work package Work package effort ±15%, hand-off date ±3 days

A team working within its Work Package tolerance does not escalate to the Project Manager. A stage forecast within stage tolerance does not escalate to the Project Board. Only when a tolerance is forecast to be breached does escalation happen.

Manage by Exception

Manage by exception is one of the seven principles and the operational expression of tolerance-based governance. It works on a simple rule:

If the forecast stays within tolerance, no escalation is needed. If a tolerance is forecast to be breached, an exception is raised to the level above.

This lets the Project Board govern without micromanaging — they only intervene when a target is heading out of bounds. Six exception types are recognised:

Exception Report — the Project Manager alerts the Project Board that a stage tolerance is forecast to be breached.

Exception Plan — a replacement plan produced to bring the project or stage back within tolerance.

Exception situation at project level — the Project Board escalates to programme or corporate when project tolerance is forecast to be breached.

Exception at stage level — the Project Board can shorten a stage or request an Exception Plan from the Project Manager.

Exception at team level — the team raises an issue to the Project Manager when a Work Package tolerance is forecast to be breached.

Exception to the Project Board from the Project Manager — when stage-level options have been exhausted and project-level tolerance is now at risk.

The principle is the same at every level: escalate only when the next-higher authority's tolerance is forecast to be breached, and bring options, not just problems.

Worked Scenario: A Tolerance Breach in Flight

A stage plan carries a cost tolerance of ±£40,000 on an £800,000 stage budget (±5%) and a time tolerance of ±10 working days. Six weeks into a twelve-week stage, the Project Manager's latest forecast shows the stage will finish £52,000 over budget — £12,000 beyond the cost tolerance — but still inside the time tolerance.

Walk the exception path level by level:

Team level. The over-spend originates in a Work Package whose own effort tolerance is ±15%. That Work Package is within its tolerance, so the Team Manager does not escalate to the Project Manager; the variance is absorbed at team level and simply noted in the Work Package status.

Stage level. Aggregated across all Work Packages, the stage forecast breaches the ±£40,000 stage cost tolerance set by the Project Board. The Project Manager must now act — this is the trigger that manage by exception is designed for.

Exception Report. The Project Manager raises an Exception Report to the Project Board — not a silent plan revision. The report states the current forecast, the cause, the impact on the seven performance targets (cost is breached; time, scope, quality, benefits, risk, and sustainability are not), and at least two options with a recommendation.

Exception direction. The Project Board gives exception direction : accept an increased stage tolerance, reduce scope to recover cost, or request an Exception Plan that re-baselines the stage.

No project-level escalation. Because project-level tolerance (set by programme or corporate) is not breached, the board handles it — the programme is not involved.

The scenario isolates the exam-critical distinctions: escalation happens only at the level whose tolerance is forecast to be breached; a variance that stays within a lower level is not escalated upward; and the Project Board, not the Project Manager, owns the re-baseline decision. A common distractor has the Project Manager quietly editing the Stage Plan to hide the breach — that violates manage by exception and the progress practice in one move.

Performance Target Trade-offs

The seven targets are coupled, and most management decisions trade one target against another. The board and Project Manager must weigh the combination , not optimise a single target in isolation. A decision that "fixes" cost by sacrificing quality or risk is rarely the best answer in a Practitioner scenario.

Decision Primary target improved Targets typically eroded
Add budget to recover schedule Time Cost (and sustainability if the rush increases waste)
Cut scope to hit the date Time, Cost Benefits, Scope
Descope quality checks to save cost Cost Quality, Risk (more defects escape)
Accept a riskier, cheaper supplier Cost Risk, Quality
Add sustainability reporting and controls Sustainability Cost, Time (usually minor)
Recover schedule with overtime Time Risk, Quality, People (fatigue, motivation)

A Practitioner item that asks "what is the best response to a forecast cost breach" almost always wants the option that protects benefits and quality while accepting a controlled cost or scope change — not the option that silently sacrifices quality or risk to protect cost, and not the option that breaches a different tolerance to save this one. Naming the trade-off explicitly, and showing you considered the effect on the other six targets, is what earns the mark.

Project Context

The project context is the fifth integrated element and the basis for tailoring. PRINCE2 is explicitly designed to be tailored to the project's environment. Key context factors:

Scale — a two-person, four-week study versus a 200-person, three-year programme.

Complexity — single-discipline versus multi-supplier, multi-site, regulatory-bound.

Risk — higher risk typically warrants shorter stages, more frequent reporting, and tighter tolerances.

Organisation — three common contexts:

Commercial — a customer–supplier relationship under contract; PRINCE2 roles split across two organisations.

Programme — the project sits inside a programme; the programme sets project tolerance and may supply the Project Board.

Internal — a single organisation delivering change for itself; roles can be collapsed.

Tailoring decisions flow from context. A small internal project may combine the Project Board into a single sponsoring executive, dispense with a separate Project Log for risks (tracking them in the Project Log but lightly), and run a single stage. A commercial programme-led project will keep full role separation, tighter tolerances, and formal stage boundaries. Both are valid PRINCE2 — the method is the same, the application differs.