Exceptions: exception reports, exception plans and the board's options

An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels. PRIN-131 studied exceptions from the point of view of the progress practice: what tolerances are, how forecasts reveal exceptions and what goes into an exception report. This lesson looks at exceptions as a journey through the processes. The project manager detects and escalates the exception in controlling a stage. The board decides in directing a project. If the board asks for an exception plan, the project manager produces it in managing a stage boundary. The board approves it in directing a project, and the project manager resumes controlling the stage against the new plan. The example comes from Ridgeline Water's rollout stage 1.

Detecting the exception

Rollout stage 1 started at week 38 with a plan to install 16,800 meters by week 68, with a time tolerance of +2 weeks (a limit of week 70), a cost tolerance of +5 % and −10 % on 3,698 thousand (an upper limit of about 3,883 thousand) and a scope tolerance down to 16,500 meters. The first 12 weeks went well. Then two things happened together. A cold January slowed outdoor work. And the crews reached the first of the newer subdivisions, where the service lines are a type of plastic pipe that needs a different meter setter and a pressure test after installation. The installation rate fell from 9 to about 6.5 meters per crew per day in those streets.

At the stage status review in week 52, the project manager reworked the forecast with Northline's latest checkpoint data. If nothing changed, the stage would finish at about week 73, three weeks beyond the time limit, at a cost of about 3,760 thousand. That forecast breaches a stage tolerance, so the decision is not the project manager's. Taking corrective action that quietly used the stage's cost tolerance to buy back time would still not fix the date. The project manager escalated with an exception report the same week, and told the executive by phone before the report arrived.

The exception report

The exception report describes the exception, its cause and consequences, the options and the project manager's recommendation, and any lessons. It is produced quickly, because the purpose is to let the board decide before the situation gets worse; it is not a detailed plan. PRIN-131 listed the contents. What matters at process level is that the report goes to the board, not to the team managers or the business layer, and that it is triggered by a forecast, not by an actual breach.

Weighing the options

Each option is checked against all the stage tolerances and the project tolerances, and its effect on the business case is stated. The code below performs that check for the four options in the report.

stage = {"cost_max": 3698 * 1.05, "end_max": 70, "scope_min": 16500}
project = {"end_max": 108, "cost_max": 9600 * 1.05}
project_cost_now = 9727 - 3698   # other stages, actual and forecast
options = {  # name: (stage cost, stage end week, meters, project end week)
    "A three extra crews": (3950, 70.5, 16800, 102),
    "B move newer subdivisions to stage 2": (3560, 69, 15400, 103),
    "C two extra crews, end week 71": (3850, 71, 16800, 101),
    "D do nothing": (3760, 73, 16800, 103),
}
for name, (cost, end, meters, p_end) in options.items():
    s = []
    if cost > stage["cost_max"]: s.append("stage cost")
    if end > stage["end_max"]: s.append("stage time")
    if meters < stage["scope_min"]: s.append("stage scope")
    p = []
    if project_cost_now + cost > project["cost_max"]: p.append("project cost")
    if p_end > project["end_max"]: p.append("project time")
    print(f"{name:38} stage: {', '.join(s) or 'within':22} project: {', '.join(p) or 'within'}")

A three extra crews                    stage: stage cost, stage time project: within
B move newer subdivisions to stage 2   stage: stage scope            project: within
C two extra crews, end week 71         stage: stage time             project: within
D do nothing                           stage: stage time             project: within

Every option except doing nothing breaches at least one stage tolerance, and doing nothing breaches the time tolerance by the most. None breaches a project tolerance, so the board can decide on its own authority. Option A breaches both stage cost and stage time. Option B stays inside cost and time but cuts scope below its limit and pushes work, at winter rates, into rollout stage 2. Option C breaches the time tolerance by one week but keeps cost within tolerance, keeps the full scope and, because the extra crews keep working into rollout stage 2, brings the project end forward to week 101. The project manager recommends C and asks the board to approve a revised stage time limit.

The board's options

When the board receives an exception report, it can ask for more information, approve a way forward that does not need a new plan (for example by approving a change the project manager could not), ask for an exception plan, or, if the project is no longer justified, instruct premature closure. If the exception would breach project tolerances, the board must refer it to the business layer. The board should respond quickly; an exception report that waits three weeks for a board meeting has lost most of its value.

The board met in week 53. The executive asked whether the newer subdivisions would also change the leak savings evidence, since one of the board's conditions at the pilot boundary was to measure leak savings in a newer subdivision. The project manager confirmed that the first results would arrive in week 60. The board requested an exception plan based on Option C, with a revised stage time limit of week 72, and asked for the survey of service line materials to be built into the plan for rollout stage 2.

Producing the exception plan

The exception plan is produced in managing a stage boundary. It is a plan like any other, with products, schedule, resources, costs, tolerances and risks, but it covers only the period from now to the end of the current stage, and it replaces the stage plan once approved. Because it changes the stage, the project manager also updates the project plan, the business case and the risk register, just as at a normal boundary, so that the board sees the whole effect of its decision. If the exception had been at project level, the exception plan would replace the project plan, and the business layer would approve it.

The board authorized the exception plan in week 55, through the same directing activity it uses for stage boundaries: authorizing a stage or exception plan. The project manager then resumed controlling the stage against the exception plan as the new baseline. Work packages were revised with Northline to add the two crews and the new setter procedure, and the team managers accepted them in managing product delivery. The next highlight report showed the stage against the new baseline, with a short note recording the exception and the board's decision.

Adding two crews changed the value of Northline's contract. Under the city's procurement code, a change order of this size within the approved budget could be approved by the general manager, so it did not need to go back to council; the state revolving fund's requirements for change orders were also checked. The commercial management approach recorded the change order alongside the exception plan.

Common problems with exceptions

The most common problem is late escalation. Project managers hope that things will recover, and wait for the actual breach before raising the exception. By then the options are fewer and worse. The second is an exception report full of narrative and short on options. The third is a board that treats an exception as a failure and looks for someone to blame, which teaches project managers to hide forecasts. PRINCE2's answer to all three is the same: an exception is the system working. Tolerances exist so that the right people make the right decisions at the right time.