Tolerances, stages and exception plans in planning

The plans practice does not stand alone. Plans are divided into management stages, carry tolerances, and are replaced by exception plans when tolerances are forecast to be exceeded. PRIN-110 explained the principles of managing by stages and by exception, and PRIN-120 looked at how tolerances shape behaviour and how exceptions are handled between people. This lesson looks at the planning side: how to choose stages, how to derive sensible tolerances from estimates, what an exception plan contains, and how plans are baselined and replanned.

Management stages and technical stages

A management stage is a section of the project that the project manager manages on behalf of the board at any one time, at the end of which the board reviews progress and decides whether to continue. A technical stage is a grouping of work by the type of specialist activity, such as design, build or test. The two are different. Technical stages may overlap; management stages do not. A management stage boundary is placed where a decision is needed, which may fall in the middle of a technical stage.

How many stages, and how long

PRINCE2 requires at least two management stages: an initiation stage and at least one further stage. Beyond that, the number and length of stages is a planning decision. Shorter stages give the board more frequent control but more overhead; longer stages save board time but allow problems to grow before the next formal review. Good stage boundaries coincide with natural decision points: the end of a pilot, a major procurement, a go-live, or the release of significant funding.

Deriving tolerances from estimates

Tolerances are often set as round percentages without reference to the estimates. A better approach uses the uncertainty in the estimates. If the plan is built on expected values and the board wants a reasonable chance of avoiding an exception from normal variation, tolerances can be set to cover a chosen range around the plan. Lesson 7 showed how three-point estimates give an approximate standard deviation; for independent activities in sequence, variances add.

import math
# critical-path work packages for the pilot stage: (optimistic, most likely, pessimistic) weeks
critical = {
    "pilot radio network": (5, 6, 9),
    "head-end configured": (4, 5, 8),
    "billing interface":   (6, 8, 14),
    "pilot live and measured": (8, 8, 10),
}
mean = sum((o + 4 * m + p) / 6 for o, m, p in critical.values())
sd = math.sqrt(sum(((p - o) / 6) ** 2 for o, m, p in critical.values()))
print(f"expected stage duration {mean:.1f} weeks, sd {sd:.1f} weeks")
for z, label in [(0.84, "about 80 %"), (1.28, "about 90 %")]:
    print(f"plan {mean:.0f} weeks; tolerance +{z * sd:.1f} weeks covers {label} of normal variation")
# cost tolerance from a rough cost estimate range
budget, cost_sd = 1450, 70        # $000
for pct in (3, 5, 8):
    z = budget * pct / 100 / cost_sd
    print(f"cost tolerance +{pct} % = {budget * pct / 100:.0f}k = {z:.1f} standard deviations")

expected stage duration 28.7 weeks, sd 1.7 weeks
plan 29 weeks; tolerance +1.4 weeks covers about 80 % of normal variation
plan 29 weeks; tolerance +2.1 weeks covers about 90 % of normal variation
cost tolerance +3 % = 44k = 0.6 standard deviations
cost tolerance +5 % = 72k = 1.0 standard deviations
cost tolerance +8 % = 116k = 1.7 standard deviations

The expected pilot duration is about 28.7 weeks, somewhat longer than the 27-week critical path from lesson 9 because the critical activities have longer pessimistic tails. With a standard deviation of about 1.7 weeks, and a plan rounded to 29 weeks, a time tolerance of about +1.4 weeks would absorb roughly four in five normal outcomes, and about +2.1 weeks nine in ten. For cost, a +5 % tolerance on a 1.45 million pilot budget is about one standard deviation of the cost estimate, while +8 % is about 1.7. These calculations rest on simplifying assumptions, such as independence and roughly normal totals, so they are a guide rather than a rule. Their value is that they connect the tolerance to the plan's real uncertainty, which helps the board choose tolerances that trigger exceptions for genuine problems rather than ordinary variation.

Tolerances at each level of plan

Tolerances appear at every level. The business layer sets project tolerances, which appear in the project plan. The board sets stage tolerances in each stage plan, within the project tolerances. The project manager sets work package tolerances, within the stage tolerances, and team managers plan their work within them. Each level keeps some tolerance in reserve: if the project manager passed the full stage tolerance down to each of three team managers, three small overruns could add up to a stage exception.

Exception plans

When a stage or project tolerance is forecast to be exceeded, the project manager raises an exception report. If the board decides that the plan cannot be recovered within tolerance, it may ask for an exception plan. An exception plan replaces the current stage plan, or the project plan if project tolerances are affected, and covers the period from now to the end of that stage or project. It has the same format as the plan it replaces, plus an explanation of the exception and the chosen response. The board approves a stage exception plan; the business layer approves a project exception plan.

An exception plan is not a punishment. It is a normal mechanism for responding to new information, and an early, well-argued exception plan is a sign of good management. What would be a sign of poor management is carrying on with a plan everyone knows is unachievable, or quietly absorbing the problem until it is too large to fix.

Baselines and replanning

Once approved, a plan becomes a baseline against which progress is measured. Plans are revised as part of normal stage boundary work: the project plan is updated with actuals and revised forecasts, the next stage plan is created, and the business case is refreshed. Changing a baselined plan outside these points requires approval, either through change control or through an exception. This discipline is what makes progress reports meaningful; if the plan is quietly revised every month, the project is always on track and the board learns nothing.

Planning closure

The final stage plan should include the activities and products needed to close the project: handing over products, confirming acceptance against the project product description, evaluating the project, handing over the benefits management approach and recommending follow-on actions. These are easily forgotten when teams are focused on delivery. Ridgeline Water's last rollout stage should therefore include decommissioning the reading routes, final acceptance after 60 days of live running, the end project report and the handover of benefits reviews to the utility's operations director.