10.1 Progress: Controls, Tolerances & Reports

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.

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:

1. 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.
2. 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.
3. 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.