Exceptions and exception plans

An exception is a situation where it can be forecast that there will be a deviation beyond the agreed tolerance levels. Exceptions are not failures of PRINCE2; they are PRINCE2 working as designed. The level of management that set a tolerance has said, in effect, tell me if this boundary will be crossed, because then the decision is mine. This lesson covers how exceptions are recognized and escalated at each level, what goes into an exception report, the options a board has, how project-level exceptions reach the business layer, and how an exception plan is approved. PRIN-130 described the planning side of exception plans; here the focus is on the decision.

Exceptions at each level

A work package exception is normally resolved by the project manager, who can move work or tolerance between work packages, approve changes within his or her authority, or adjust the work package. It becomes a stage exception only if the project manager cannot resolve it within the stage tolerances. Likewise, the board can absorb a stage exception within the project tolerances, for example by approving a stage exception plan with revised stage tolerances, as long as the project as a whole remains within the limits the business layer set. Each level tries to solve problems within its own authority before passing them up, but none hides a forecast breach of a tolerance it does not control.

Raising an exception early

The value of an exception lies in its timing. Raised early, it gives the board options; raised late, it gives the board a bill. The project manager should raise an exception report as soon as a forecast breach is reasonably certain, even if the forecast may later improve. The board can always decide to take no action other than watching. What the board cannot do is recover time that has already passed. A culture in which project managers fear raising exceptions, perhaps because they are treated as personal failures, defeats the whole mechanism: the board then learns of breaches only when they become actual.

The exception report

In plain terms, an exception report describes the situation, explains its cause, sets out its consequences for the stage and the project, lists the available options with their effects on the performance targets and the business case, makes a recommendation and records any lessons. It should be short enough to read in a board meeting and specific enough to decide from. It is prepared by the project manager and may draw on issue reports, risk assessments and forecasts. An exception report often accompanies or follows informal warning in highlight reports.

Options and their evaluation

The options in an exception report should be genuine alternatives, not one recommendation and two straw men. They usually include some combination of using a different method to recover within tolerance, reducing scope or quality within acceptable limits, accepting the deviation with revised tolerances, and, for serious exceptions, closing the project prematurely. Each option should show its effect on all the performance targets and on the business case, because an option that fixes cost by delaying benefits may not be better overall.

tol = {"cost": 1522, "time": 31, "scope_min": 2500, "quality_min": 97.0}
options = {
    # name: (stage cost k, stage weeks, connections, read rate %, effect on project NPV k)
    "A reduce pilot to 2,500 connections": (1530, 29.5, 2500, 97.4, -15),
    "B revised stage cost tolerance": (1568, 30.0, 2800, 97.6, -35),
    "C defer portal features to rollout": (1516, 29.5, 2800, 97.4, -60),
    "D manual data cleansing by staff": (1505, 33.0, 2800, 97.4, -25),
    "E close project prematurely": (1250, 26.0, 0, 0.0, -2309),
}
for name, (cost, weeks, conn, rate, npv) in options.items():
    fails = []
    if cost > tol["cost"]: fails.append("cost")
    if weeks > tol["time"]: fails.append("time")
    if conn < tol["scope_min"]: fails.append("scope")
    if rate < tol["quality_min"]: fails.append("quality")
    verdict = "within current tolerances" if not fails else "breaches " + ", ".join(fails)
    print(f"{name:38} NPV effect {npv:6}k  {verdict}")

A reduce pilot to 2,500 connections    NPV effect    -15k  breaches cost
B revised stage cost tolerance         NPV effect    -35k  breaches cost
C defer portal features to rollout     NPV effect    -60k  within current tolerances
D manual data cleansing by staff       NPV effect    -25k  breaches time
E close project prematurely            NPV effect  -2309k  breaches scope, quality

Option A just misses the cost tolerance and uses the bottom of the scope tolerance. Option B breaches cost tolerance by design: it asks the board to approve a revised tolerance. Option C stays within every current tolerance but costs the most of the recovery options in NPV terms, because deferring portal features delays the customer benefits. Option D breaches time tolerance because staff can clean data only part-time. Option E, premature closure, would lose the whole NPV of the do-something option from PRIN-130's appraisal and is listed only to show the board the cost of stopping. The project manager recommends B: it keeps the full pilot scope and quality, has a modest NPV effect, and the project tolerance can absorb the extra 46 thousand. C is a reasonable alternative if the board prefers to stay within current tolerances.

The board's responses

When it receives an exception report, the board may respond in several ways. It may ask for more information before deciding. It may decide that the situation can be handled within current tolerances after all, for example by approving a change or a recovery action that the project manager could not authorize. It may approve the recommended option and ask the project manager to produce an exception plan. It may reject all options and instruct a different course. Or, if the project is no longer justified, it may decide to close the project prematurely. If the exception would also exceed project tolerances, the board cannot approve a solution on its own authority and must refer the matter to the business layer.

The exception plan and exception assessment

If the board requests one, the project manager prepares an exception plan. It replaces the remainder of the current stage plan, or of the project plan if project tolerances are affected, and has the same format as the plan it replaces. Its preparation is handled in the managing a stage boundary process, which also updates the business case, risk register and project plan to reflect the exception. The board then holds an exception assessment, which is a decision point like a stage boundary: it reviews the exception plan, the updated business case and risks, and decides whether to approve the plan and continue. An approved exception plan becomes the new baseline.

Project-level exceptions

When an exception threatens project tolerance, the board refers it to the business layer with its own view. The business layer may approve new project tolerances, change the project's objectives, accept a reduced scope or close the project. In public organizations this may involve a formal approval route. Because these decisions often take longer, the board should warn the business layer early, through whatever regular reporting it has agreed, that a project-level exception is becoming likely.

In a Canadian federal department, for example, significant changes to a project's cost, schedule or scope may need to return to the department's senior governance committees, and for larger projects to Treasury Board, under the Policy on Planning and Investment and the Directive on the Management of Projects and Programmes; municipalities usually need council approval for budget increases beyond delegated limits. Check the current versions of these instruments and your organization's delegation of financial authority, because they define who the business layer really is for your project.