PRINCE2 2017 Progress Theme: Tolerances, Controls and Exceptions

Executive summary

Purpose of the Progress theme

The Progress theme establishes mechanisms to monitor and compare actual achievement with planned achievement, forecast whether objectives and tolerances can still be met, and control unacceptable deviations. Progress is monitored at work-package, management-stage and whole-project levels.

The source explicitly connects this theme to manage by exception. Senior management should not need every operational detail when work remains within agreed authority. Instead, each level receives the information needed to judge whether the lower level remains within tolerance and whether a management decision is required.

This approach depends on reliable forecasts. Waiting until a tolerance has already been exceeded is too late because the delegated authority has effectively been consumed. The Project Manager should escalate when the stage is forecast to exceed tolerance; the Team Manager should raise an issue when a Work Package is forecast to exceed its tolerance.

Minimum control requirements

The project should define its approach to progress control in the Project Initiation Documentation. It should be managed by stages, set tolerances and use manage by exception against those tolerances. When exceptions are raised, business justification should be reviewed, and lessons should continue to be captured and applied.

These requirements connect several principles rather than creating an isolated reporting system. Manage by stages provides the control intervals. Manage by exception delegates authority. Continued business justification prevents a project from mechanically pursuing a failed baseline. Learn from experience improves forecasts and corrective actions.

A control design should therefore answer: what is the baseline, who has authority, what tolerance applies, how often will progress be measured, what events trigger decisions, what information will be reported, and what happens when the forecast falls outside tolerance?

Time-driven and event-driven controls

Time-driven controls occur at predefined intervals. The source examples include weekly Checkpoint Reports and monthly Highlight Reports. Their purpose is routine monitoring and communication. Frequency should be tailored to the level of control required. An inexperienced team, high-risk stage or rapidly changing environment may justify more frequent reporting.

Event-driven controls occur when a specific event happens. Examples in the source include end-stage assessment, completion of the PID and creation of an Exception Report. These controls often support decisions rather than periodic status communication.

The supplied rationale material reinforces this distinction. A Checkpoint Report and Highlight Report are typical time-driven controls. An Exception Report is event-driven because it is created by a forecast loss of tolerance rather than by the calendar. A Daily Log is a record, not one of these formal controls.

Baselines for progress control

The detail in the plan determines the detail at which progress can be controlled. The Project Plan provides project-level targets and tolerances and is the Project Board’s principal overall baseline. The Stage Plan provides the detailed baseline for the Project Manager’s current stage. A Work Package defines the specialist commitment and its tolerance. An Exception Plan, when approved, replaces the plan that can no longer be achieved within tolerance.

Control should compare like with like. A Team Manager should not be judged against the entire Project Plan; they are accountable for the products and constraints in the authorised Work Package. The Project Manager should not use an informal team schedule as a substitute for the approved Stage Plan when deciding whether stage tolerance is threatened.

Baselines also include product and quality information. Progress is not only percentage-complete activity. Product status, quality results and approvals often provide more objective evidence of achievement than subjective estimates of task completion.

Delegating tolerance

The commissioning authority sets project tolerance for the Project Board. Within those limits, the board can continue, change or stop the project and delegates stage tolerance to the Project Manager. The Project Manager operates the stage within that authority and agrees Work Package tolerances with Team Managers.

Tolerance can be set against the performance objectives identified by the method, including time, cost, quality, scope, benefits and risk. It is a limit of delegated authority, not a target to be used up. A tolerance of plus or minus a value does not mean the team should plan to deliver at the worst permitted boundary.

Clear tolerance avoids both micromanagement and uncontrolled delegation. If there is no quantified or otherwise explicit limit, the lower level cannot know when it is authorised to act independently and the upper level cannot know when it should expect escalation.

Raising exceptions and issues

If the Project Manager forecasts a stage deviation beyond stage tolerance, an Exception Report is raised to the Project Board. The board can request an Exception Plan, remove the cause, adjust tolerance if it has authority, request more information, reject a recommendation or otherwise direct corrective action. Approval of a stage Exception Plan establishes the revised management baseline.

If the Project Board forecasts that project tolerance will be exceeded, it escalates to the commissioning authority. The board cannot simply grant itself more authority. The same logic applies below the Project Manager: a Team Manager does not raise a PRINCE2 project/stage exception directly to the board. A forecast Work Package deviation is raised as an issue to the Project Manager, who determines whether corrective action can remain within stage tolerance.

Good escalation is early and decision-oriented. An Exception Report should explain the cause, consequences, options and recommendation sufficiently for the next level to decide. It should not be merely a red status indicator with no recovery analysis.

Reviewing progress with registers and product status

The source identifies several management products that support progress review. The Issue Register shows formal issues and their state. The Risk Register shows current threats and opportunities. The Quality Register shows planned and completed quality activities. A Product Status Account provides a snapshot of the status of products for a project, stage or defined area. The Daily Log captures actions, informal issues and observations.

These records allow the Project Manager to test narrative status reports against evidence. A team may report that work is “90% complete”, but if key product approvals are overdue and important quality activities have not occurred, the project is not as advanced as the percentage suggests.

Progress review should therefore combine schedule/cost data with product completion, quality evidence, risk exposure, issue trends and forecasts. The purpose is to predict whether the authorised plan can still be achieved, not simply to document what happened last week.

Reporting and learning

Checkpoint Reports provide the Project Manager with progress against Work Packages and are normally produced by Team Managers. Highlight Reports give the Project Board a concise picture of project or stage progress. End Stage Reports summarise performance and the overall project situation at a stage boundary and, together with the next Stage Plan, support the decision to continue. The End Project Report provides information for evaluation and closure.

Lessons are captured throughout the project in a Lessons Log and, for larger projects, may be consolidated into a Lessons Report. Lessons can also be included in stage and project reports. The source expects lessons to be made available for future projects and organisational learning rather than remaining as a closure formality.

Tailor report frequency and form, but keep the management interface intact. A dashboard can replace a document, and an automated system can generate status, provided the right role receives reliable information at the frequency and decision point required.

Practical verification checklist

• Define progress controls and reporting in the project initiation baseline.
• Set explicit project, stage and Work Package tolerances.
• Use periodic Checkpoint and Highlight reporting at frequencies matched to risk and capability.
• Use event-driven controls for decision points such as stage boundaries and forecast exceptions.
• Compare progress against the correct baseline for each management level.
• Forecast tolerance consumption rather than waiting for an actual breach.
• Raise an Exception Report when stage tolerance is forecast to be exceeded.
• Route Work Package deviations to the Project Manager as issues.
• Use registers, quality information and product status to validate narrative progress.
• Capture and transfer lessons throughout the project.

Common mistakes to avoid

• Treating tolerance as a target rather than a delegated limit.
• Waiting until the tolerance is actually breached before escalating.
• Confusing time-driven Highlight/Checkpoint Reports with event-driven Exception Reports.
• Escalating a Work Package issue directly as a board-level exception.
• Reporting task percentages without checking product and quality status.
• Increasing tolerances informally to hide poor performance.

Related KEVOS handbook pages