The Boundary That Came Early

Tolerance is the trigger, not the calendar. The project manager's delegated authority is bounded by the stage tolerances. The moment a forecast shows a tolerance will be exceeded, the situation is an exception - PRINCE2 requires escalation as soon as it is identified, not at the next convenient governance event. Here both cost (forecast £410k against £300k) and time (forecast 4 weeks against 2) breach.

Why waiting is wrong:

• By week 16 the overspend is actual, not forecast. The board has lost the option to avoid it.
• An exception at the boundary forces the project manager to produce a next stage plan built on out-of-tolerance foundations - it cannot be approved honestly.
• Four weeks of unreported breach is precisely the loss of control the principle exists to prevent.

Charging the cost to stage 4 is worse. Stage 4's plan has not been authorised, so its budget is not a fund the project manager can draw on; doing so transfers an exception into an unauthorised future stage and conceals it from the board. That is not delegation, it is misreporting.

The correct action is an exception report now: cause (loss of a key resource), effect (cost, time, quality of design, risk), and options with a recommendation - accept the delay, source an alternative engineer, or reduce the design scope.

It is a legitimate statement of principle, misapplied. Tolerances are set precisely so the executive is troubled only with exceptions - the project manager is right to absorb in-tolerance issues silently. But this is an exception, so escalating is compliance with the instruction, not a breach of it.

The instruction becomes a governance failure in two ways:

• If applied literally, it means the project manager decides what counts as an exception. The board has lost control of its own tolerance thresholds.
• It invites the project manager to find ways to keep bad news below the line - exactly what charging stage 4 was.

What to do:

• In the exception report, state plainly that the forecast breach is outside delegated authority and therefore requires board direction under manage by exception.
• Ask the executive to either (a) confirm the existing tolerances stand and direct the project manager, or (b) formally widen them and record the new limits and rationale.
• Take it through project assurance if the executive deflects, since assurance reports to the board, not the project manager.
• Record the exchange in the lessons log: tolerance-setting and escalation expectations should be part of the initiation conversation with the executive.

Scope of the exception plan. It replaces the plan for the remainder of the current stage - from the point the exception arose to the end of stage 3 - not the whole project. It must show how the estimated overspend and delay will be recovered or accommodated.

Consistency requirements: it is derived from, and must remain consistent with, the project plan and the business case. If it cannot be, then the project plan itself needs re-baselining, which is a bigger decision for the board.

Products to update before the board decides:

• Business case - re-test the justification against revised cost and benefit timing.
• Plans - exception plan plus amended stage 4 outline if the boundary moves.
• Risk register - resource dependency on the subcontractor, design quality risk from replacement staff.
• Quality - quality register and affected product descriptions, if design reviews are re-sequenced.
• Issues register and lessons log - the lessons report is a required input to the end stage assessment.

The sequence: exception report → board direction → exception plan prepared and assessed → if approved, the plan becomes the new baseline and work resumes under it. The board may equally decide to change tolerances, take corrective action itself, or stop the project - the exception plan is one option, not the automatic outcome.