The progress practice I: management by exception and tolerances

The progress practice answers three questions throughout the project: where are we now compared with the plan, where are we likely to end up, and does anyone above the current level of management need to make a decision? In plain terms, its purpose is to establish mechanisms to monitor and compare actual achievements against those planned, to forecast the project's objectives and continued viability, and to control any unacceptable deviations. This lesson looks at how progress control is built on delegated authority and tolerances. Lesson 8 covers the controls and reports, and lesson 9 covers what happens when tolerances are forecast to be exceeded.

Delegation and management by exception

PRIN-110 described manage by exception as a principle and PRIN-120 looked at how tolerances shape behavior. The progress practice turns the principle into a working system. Each level of management delegates authority to the level below, sets tolerances within which that level may act without referring back, and receives reports that allow it to confirm everything is within tolerance. The level above intervenes only when a tolerance is forecast to be exceeded. This lets senior people spend their limited time on the decisions that genuinely need them, while those closer to the work keep control of day-to-day matters.

The seven performance targets

PRINCE2 7 sets tolerances on seven performance targets: time, cost, scope, quality, benefits, risk and sustainability. Time and cost tolerances are familiar. Scope tolerance allows some flexibility in what is delivered, often expressed through priorities such as MoSCoW. Quality tolerance allows a range around quality criteria. Benefits tolerance is set at project level, because benefits usually arise after the project, and is expressed against the business case. Risk tolerance limits the exposure the board will accept before escalation. Sustainability tolerance, introduced as a performance target in the seventh edition, allows a range around sustainability targets such as emissions or waste.

Forecasts, not actuals

A crucial feature of progress control is that exceptions are triggered by forecasts, not by actual breaches. If the stage cost tolerance is 72 thousand, the project manager does not wait until 72 thousand has actually been overspent; he or she raises an exception report as soon as the forecast cost at the end of the stage exceeds the tolerance. Waiting for the actual breach would mean the board learns of the problem when it is too late to do anything except pay. The value of tolerances lies in early warning.

This makes forecasting a core skill of the progress practice. A forecast combines what has been done, what has been spent, what remains and the best current estimate of how long and how much the remainder will take. Lesson 8 shows how earned value can support forecasts; here we look at how forecasts are compared with tolerances across all seven targets.

The code below is a simple tolerance check. For each performance target it holds the plan, the tolerance band and the current forecast, and it reports how much of the tolerance has been used and whether an exception is needed. It treats the quality and scope targets as lower limits, because falling below them is the problem, and the time and cost targets as two-sided bands.

targets = {
    # name: (plan, lower limit, upper limit, forecast)
    "time (weeks)":        (29, 27, 31, 30.5),
    "cost (thousand)":     (1450, 1305, 1522, 1508),
    "scope (connections)": (3000, 2500, None, 2800),
    "quality (read rate %)": (98.0, 97.0, None, 97.4),
    "risk (largest EV, k)":  (None, None, 100, 96),
}
exception = False
for name, (plan, lo, hi, fc) in targets.items():
    if hi is not None and fc > hi:
        state = "FORECAST BREACH"; exception = True
    elif lo is not None and fc < lo:
        state = "FORECAST BREACH"; exception = True
    else:
        used = ""
        if plan is not None and hi is not None and fc > plan:
            used = f"{(fc - plan) / (hi - plan):.0%} of upper tolerance used"
        elif plan is not None and lo is not None and fc < plan:
            used = f"{(plan - fc) / (plan - lo):.0%} of lower tolerance used"
        elif plan is None:
            used = f"{fc / hi:.0%} of limit"
        state = "within tolerance " + used
    print(f"{name:22} forecast {fc:>7} {state}")
print("raise exception report" if exception else "no exception: report status in the highlight report")

time (weeks)           forecast    30.5 within tolerance 75% of upper tolerance used
cost (thousand)        forecast    1508 within tolerance 81% of upper tolerance used
scope (connections)    forecast    2800 within tolerance 40% of lower tolerance used
quality (read rate %)  forecast    97.4 within tolerance 60% of lower tolerance used
risk (largest EV, k)   forecast      96 within tolerance 96% of limit
no exception: report status in the highlight report

Every target is within tolerance, but the picture is not comfortable. The time forecast has used 75 % of the upper time tolerance and cost has used 81 % of the upper cost tolerance. Scope has used 40 % of its lower tolerance, quality at 97.4 % has used 60 % of the quality tolerance, and the largest risk sits at 96 % of the risk limit. No exception report is needed yet, but the highlight report should show the board how close the stage is running to several limits at once. A board that sees this pattern may choose to act early, for example by agreeing to a change that buys back time, rather than waiting for a formal exception.

How likely is an exception?

Tolerances are set when the stage plan is approved, using estimates that are uncertain. Lesson 4 showed that risks have probabilities; the progress practice can combine the plan's uncertainty and the risks to estimate how likely the stage is to breach its cost tolerance. The code below runs a simple Monte Carlo simulation of the pilot stage cost: each work package cost varies around its estimate, and the main threats occur with their probabilities. It is a teaching model with simplified assumptions.

import random
random.seed(131)
packages = {"network": (600, 0.06), "billing interface": (500, 0.10), "customer change": (350, 0.08)}  # mean, relative sd
threats = [(0.35, 90), (0.60, 160 * 0.5), (0.15, 220 * 0.5), (0.60, 45)]  # probability, cost impact after responses
plan, tol = 1450, 72
runs, breaches, totals = 20000, 0, []
for _ in range(runs):
    cost = sum(random.gauss(m, m * sd) for m, sd in packages.values())
    cost += sum(c for p, c in threats if random.random() < p)
    totals.append(cost)
    if cost > plan + tol:
        breaches += 1
totals.sort()
print(f"median stage cost {totals[runs // 2]:.0f}; 80th percentile {totals[int(runs * 0.8)]:.0f}")
print(f"probability of exceeding cost tolerance {breaches / runs:.0%}")

median stage cost 1571; 80th percentile 1658
probability of exceeding cost tolerance 69%

The simulation suggests a median stage cost of about 1,571 thousand and an 80th percentile of about 1,658 thousand, with about a 69 % chance, better than two in three, of exceeding the 1,522 thousand upper tolerance. That is because the plan of 1,450 thousand includes no allowance for the threats: their expected costs sit partly in the risk budget, which is outside the stage budget. The board has three sensible choices: accept that an exception is quite likely and treat it as a planned decision point, widen the cost tolerance, or move some of the risk budget into the stage budget for responses that are almost certain to be needed. What it should not do is approve the plan believing an exception is unlikely.

Tolerances for work packages and products

The project manager sets work package tolerances, usually on time and cost, sometimes on scope or quality, and keeps part of the stage tolerance in reserve, as PRIN-130 showed. Products themselves have quality tolerances, written in their product descriptions: for example, the radio network must reach at least 98 % of pilot addresses, with 97 % acceptable in areas the survey classed as difficult. A product that falls outside its quality tolerance becomes an off-specification. In this way the progress, quality and issues practices share the same tolerance system at different levels.