Study guide
10.1 Progress: Controls, Tolerances & Reports
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
10.1 Progress: Controls, Tolerances & Reports
Key Takeaways Explain This Topic AI
The Progress practice monitors actual achievements against plans, forecasts objectives, and controls deviations using event-driven and time-driven controls.
Tolerances are set per performance target at each management level (project, stage, team), linking Progress directly to manage by exception.
Five core reports flow upward: Checkpoint, Highlight, End Stage, End Project, and Exception — each with a defined sender, recipient, and trigger.
Event-driven controls fire on a defined occurrence (stage end, Work Package completion); time-driven controls fire on a schedule (daily, weekly, monthly).
Last updated: August 2026
The Purpose of the Progress Practice
The Progress practice establishes the mechanisms used to monitor and compare actual achievements against the plans that authorised the work, to forecast the project's ability to meet its objectives, and to control any deviations from the planned trajectory. Progress is the practice that answers the constant project question: are we where we said we would be, and if not, what are we going to do about it? Without Progress, plans are static documents; with it, they become living controls that trigger action.
Progress is monitored against three layers of plans: the Project Plan (the overall baseline used by the Project Board), the Stage Plans (the detailed baselines for the current management stage), and the Team Plans (the Team Manager's working view of a Work Package). Comparing actual progress against the correct layer is essential — a Team Manager does not assess progress against the Project Plan, and the Project Board does not assess progress against a Team Plan.
Two Control Types: Event-Driven and Time-Driven
PRINCE2 distinguishes two families of control, and the Practitioner exam frequently tests the distinction.
Event-Driven Controls
An event-driven control is triggered by a defined occurrence — something happening that was predetermined as a control point. Examples include the end of a management stage, the completion of a Work Package, the approval of an Exception Report, or the closure of the project. Event-driven controls are not tied to the calendar; they fire when the event happens, however early or late that is.
Time-Driven Controls
A time-driven control is triggered by the passage of time — at regular, scheduled intervals. Examples include a daily Checkpoint Report from a Team Manager, a weekly Highlight Report from the Project Manager to the Project Board, or a monthly financial status review. Time-driven controls give the project a steady heartbeat of information regardless of whether a planned event has occurred.
The distinction matters because the exam presents scenarios and asks which control type applies. A stage boundary is event-driven (it fires when the stage ends, not on a fixed date). A Highlight Report is time-driven (it is produced on a cadence, for example every Friday, whether or not anything notable happened). A Work Package completion is event-driven. A Checkpoint Report is time-driven.
Tolerances and Manage by Exception
Progress is the practice that operationalises manage by exception . Each management level — project, stage, and team — is given a tolerance for each of the (now seven) performance targets. Tolerance defines the permissible deviation before the next level up must be alerted. If actual progress stays within tolerance, the lower level continues without escalation; if tolerance is breached on any target, an Exception Report is raised and the next level up takes a decision.
This is why tolerances must be set per performance target and per level . A stage may have a cost tolerance of ±£20,000 and a time tolerance of ±10 working days. Breaching either — even if the other is fine — triggers an exception. Tolerances link Progress to the Plans practice (which sets them) and to the Directing and Managing processes (which respond to breaches).
Progress Reports: Who, to Whom, and When
Five reports carry progress information upward. The table below summarises the sender, recipient, and trigger for each.
- Report From To Trigger
- Checkpoint Report Team Manager Project Manager Time-driven (e.g., weekly)
- Highlight Report Project Manager Project Board Time-driven (e.g., monthly)
- End Stage Report Project Manager Project Board Event-driven (stage end)
- End Project Report Project Manager Project Board Event-driven (project closure)
- Exception Report Project Manager (or Team Manager) Project Board (via PM) Event-driven (tolerance breached)
The Checkpoint Report is the most granular: a Team Manager reports progress on a Work Package to the Project Manager on a regular cadence. The Highlight Report summarises stage progress for the Project Board between stage boundaries — it is the board's routine window onto the project. The End Stage Report is produced at every stage boundary and requests the board's authorisation to proceed to the next stage; it is event-driven because it fires on stage completion, not on a date. The End Project Report is produced at project closure and confirms what was delivered against what was approved. The Exception Report is produced whenever a tolerance is breached and a decision is needed from the next level up.
Common Exam Scenarios
Three scenario patterns recur in the Practitioner paper:
Choosing event-driven vs time-driven. The scenario describes a control ("a report is produced at the end of each management stage") and asks which type it is. End-of-stage is event-driven; "every Friday" is time-driven.
Which report goes to whom and when. The scenario names a sender and a recipient ("the Team Manager wants to update the Project Manager on Work Package progress") and asks which report is appropriate — Checkpoint Report.
What triggers an End Stage Report. The scenario asks what causes the End Stage Report to be produced. The trigger is the end of a management stage, an event — not a calendar date.
A useful rule of thumb: if the trigger contains the word when followed by an occurrence ("when a stage ends"), it is event-driven; if it contains a frequency ("weekly," "monthly," "each Friday"), it is time-driven.