Directing a project II: authorizations, ad hoc direction and escalation

Lesson 6 introduced the board's role and the five activities of directing a project. This lesson examines what the board actually checks when it makes each authorization, what options it has, how ad hoc direction works in practice, and how escalation flows between the project manager, the board and the business layer. It concentrates on the decisions relevant to the early processes, authorizing initiation and authorizing the project, and treats stage and closure authorizations in outline, since PRIN-141 covers the stage boundary and closing processes that feed them.

Authorize initiation

The board's first decision answers one question: is it worth investing in initiation? It is a small decision compared with authorizing the project, and the board should make it quickly. The board reviews the project brief and the initiation stage plan and checks a handful of things: that the outline business case shows the project is likely to be worthwhile; that the project management team is complete enough to initiate, with roles accepted; that the project approach is reasonable; that the initiation stage plan is proportionate and its tolerances are acceptable; and that the business layer's project tolerances are recorded.

If the board approves, it authorizes the initiation stage, sets its tolerances (usually confirming those proposed in the plan), and informs interested parties, including the business layer and the people whose time the stage will use. If it does not approve, it may ask for changes to the brief or the plan, or decide not to proceed. Ridgeline Water's board approves initiation with the proposed tolerances and asks the executive to brief the union about possible changes to meter readers' roles, because the outline business case names that dis-benefit.

Authorize the project

At the end of initiation, the board decides whether to commit to the project as a whole. This is a much bigger decision. The board reviews the PID and checks that the detailed business case justifies the project, that the project plan is achievable within project tolerances, that the management approaches and controls are adequate, that the benefits management approach describes how and when benefits will be measured, and that the risks are acceptable. Because managing a stage boundary has also produced the first delivery stage plan, the board usually authorizes that stage in the same meeting.

A decision not to authorize the project after initiation is not a failure of initiation. It is initiation doing its job: the organization has spent a small amount to learn that the large amount would not be worthwhile. A board that always authorizes projects after initiation should ask whether its initiation stages are finding out anything at all.

Authorize a stage or exception plan

At each later stage boundary, the board reviews the end stage report for the stage just finished and the stage plan for the next one, together with the updated business case, project plan and risks. It decides whether the project is still justified and whether to authorize the next stage, with its tolerances. When a stage tolerance has been forecast to be exceeded and the board has asked for an exception plan, the same activity is used to approve or reject the exception plan. PRIN-141 covers how the project manager prepares these products; here we look at the decision logic.

The board has four broad choices at a stage boundary: authorize the next stage as planned; authorize it with changed tolerances or conditions; ask for the plan to be revised; or close the project prematurely. Premature closure is a legitimate result of a stage boundary review. If, for example, Ridgeline Water's pilot shows that customers do not act on leak alerts, so the leak saving is far below the forecast, the detailed business case may no longer justify rolling out to all districts, and the right decision may be to stop after the pilot and use what was learned.

A stage boundary decision simulator

The code below turns the board's decision logic into a simple rule set and applies it to three invented situations at Ridgeline Water's end-of-pilot stage boundary. It checks whether the business case is still justified within benefits tolerance, whether the next stage plan fits within the remaining project tolerances, and whether risks are within the risk tolerance. Real boards apply judgement, not rules; the point is to make the checks explicit.

project = {"cost_budget": 9600, "cost_tol": 0.05, "benefit_base": 1240, "benefit_tol": 0.10, "risk_limit": 400}
def decide(name, spent_so_far, remaining_forecast, annual_benefit, risk_exposure, next_plan_ok):
    cost_limit = project["cost_budget"] * (1 + project["cost_tol"])
    total = spent_so_far + remaining_forecast
    benefit_floor = project["benefit_base"] * (1 - project["benefit_tol"])
    reasons = []
    if annual_benefit < benefit_floor:
        reasons.append(f"benefit {annual_benefit} below floor {benefit_floor:.0f}")
    if total > cost_limit:
        reasons.append(f"forecast cost {total:,} above project limit {cost_limit:,.0f}")
    if risk_exposure > project["risk_limit"]:
        reasons.append(f"risk exposure {risk_exposure} above limit {project['risk_limit']}")
    if reasons:
        verdict = "refer to business layer" if any("project limit" in r or "floor" in r for r in reasons) else "ask for revised plan"
    elif not next_plan_ok:
        verdict = "ask for revised plan"
    else:
        verdict = "authorize next stage"
    print(f"{name:22} -> {verdict}" + ("" if not reasons else "  (" + "; ".join(reasons) + ")"))
decide("A: pilot as expected", 1610, 7990, 1250, 260, True)
decide("B: leak benefit weak", 1610, 7990, 1050, 300, True)
decide("C: costs rising", 1650, 8600, 1240, 340, True)

A: pilot as expected   -> authorize next stage
B: leak benefit weak   -> refer to business layer  (benefit 1050 below floor 1116)
C: costs rising        -> refer to business layer  (forecast cost 10,250 above project limit 10,080)

In situation A the project remains justified and within tolerances, so the board authorizes the rollout stage. In B the annual benefit has fallen below the benefits tolerance floor of 1,116 thousand, and in C the forecast total cost exceeds the project cost limit of 10,080 thousand. Both are outside project tolerances, which belong to the business layer, so the board cannot simply approve the next stage: it must refer the situation to the general manager, perhaps with a recommendation to stop, rescope or accept a revised business case.

Give ad hoc direction

Between authorizations, the board gives ad hoc direction. It responds to requests for advice from the project manager, reviews highlight reports and responds if they reveal concerns, makes decisions on issues the project manager has escalated, responds to exception reports by asking for an exception plan or otherwise, and passes on information from the business layer, such as a change in corporate strategy. Ad hoc direction can be given by any board member within their responsibilities, but decisions that change tolerances or commit resources should come from the board, usually through the executive.

One caution applies. Ad hoc direction must not undermine the project manager's authority. If individual board members give instructions directly to team members, bypass the project manager or change priorities informally, the project ends up with several bosses and no clear plan. Direction should go through the project manager and, where it changes a baseline, through change control.

Escalation in both directions

Escalation in PRINCE2 follows the levels of management. Team managers escalate to the project manager when a work package is forecast to exceed its tolerances. The project manager escalates to the board when a stage is forecast to exceed its tolerances. The board escalates to the business layer when the project is forecast to exceed project tolerances. Each level can act within its own authority but must escalate beyond it. Direction flows the other way: the business layer sets project tolerances, the board sets stage tolerances, and the project manager sets work package tolerances.

Authorize project closure

The last activity of directing is to authorize project closure. Closing a project, the subject of PRIN-141, produces an end project report, a lessons report, confirmation that products have been accepted and handed over, and an updated benefits management approach covering benefits reviews after the project. The board checks these, confirms that the project can close, notifies the business layer and other interested parties, and releases the resources the project used. Responsibility for post-project benefits reviews passes to the business layer.