2.3 Performance Targets, Tolerances & Project Context

The Seven Project Performance Targets

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

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

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:

1. Exception Report — the Project Manager alerts the Project Board that a stage tolerance is forecast to be breached.
2. Exception Plan — a replacement plan produced to bring the project or stage back within tolerance.
3. Exception situation at project level — the Project Board escalates to programme or corporate when project tolerance is forecast to be breached.
4. Exception at stage level — the Project Board can shorten a stage or request an Exception Plan from the Project Manager.
5. Exception at team level — the team raises an issue to the Project Manager when a Work Package tolerance is forecast to be breached.
6. 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:

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

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.