Directing a project I: the project board's role and decisions

Directing a project is the process through which the project board is accountable for the project's success. It starts when starting up sends the request to initiate and ends when the board authorizes project closure. Unlike the managing processes, it is not a sequence of activities carried out day to day. It is a set of decision points, plus continuous availability for advice and direction. This lesson looks at the board's role, the principle of management by exception that shapes it, and the five activities of directing. Lesson 7 looks at the authorization decisions in more depth.

The purpose of directing a project

In plain terms, directing a project lets the project board make the key decisions that only it can make, while delegating day-to-day management to the project manager. The board is accountable to the business layer for the project, and it exercises that accountability through a small number of formal decisions at defined points, through tolerances that set how much freedom the project manager has, and through the reports and escalations it receives. It does not attend daily stand-ups, approve every purchase or rewrite plans.

The objectives of directing can be summarized as follows. There is authority to initiate the project. There is authority to deliver the project's products. Management direction and control are provided throughout the project's life, and the project remains viable. Corporate, program or customer management has an interface to the project. There is authority to close the project. Plans for realizing the post-project benefits are managed and reviewed. Each of these objectives maps onto one or more of the activities described below.

The five activities

Authorize the project and authorize a stage often happen at the same meeting at the end of initiation. The board approves the PID, which authorizes the project as a whole, and in the same meeting approves the stage plan for the first delivery stage. Some organizations record these as two decisions to keep the distinction clear: authorizing the project is a commitment to the whole investment in principle, but money is released stage by stage.

Management by exception

Management by exception is one of PRINCE2's principles and the key to how directing works. The board sets tolerances for each stage on the performance targets: time, cost, scope, quality, benefits, risk and, in PRINCE2 7, sustainability. As long as the project manager forecasts that the stage will finish within those tolerances, the board does not need to be involved in day-to-day decisions. When a forecast shows a tolerance will be exceeded, the project manager escalates through an exception report, and the board decides what to do. PRIN-131 studied tolerances and exceptions from the progress practice's side.

Management by exception makes the board's time valuable instead of wasted. A board that meets weekly to review every task trains its project manager to wait for instructions. A board that sets clear tolerances, reads concise highlight reports and responds promptly to exceptions trains its project manager to manage. The test of a well-directed project is not how often the board meets but how quickly it responds when it is needed.

Board meetings and event-driven decisions

PRINCE2 does not require the board to hold regular progress meetings. The formal decisions happen at defined events: the request to initiate, the end of initiation, each stage boundary, an exception plan and closure. Between these, the board receives time-driven highlight reports and can respond to them without meeting. Many organizations still hold monthly board meetings, which is fine if they are used for direction rather than status reporting; if a meeting is spent reading out the highlight report, it adds nothing the report did not already provide.

Ridgeline Water's lessons log contained a lesson from a pipe renewal project whose board met only quarterly, so decisions waited up to 11 weeks. Its project management team design therefore includes monthly board meetings during delivery, decisions at stage boundaries scheduled in the plan, and an agreement that exception reports will be considered within five working days, by email if needed. The executive can make urgent decisions on the board's behalf, with the others informed.

The board's responsibilities in directing

The board is not a democracy. Senior users and senior suppliers advise and commit resources, but the executive makes the decision, because the executive is accountable for the business case. In practice, a good executive seeks consensus, and a decision the senior user cannot support is a warning sign about benefits. But if the board cannot agree, the executive decides, and if the executive cannot decide within project tolerances, the matter goes to the business layer.

Reviewing the board's decision log

An assurance check sometimes looks at how a board has been directing: how long decisions took, whether exceptions were handled promptly and whether the board strayed into managing. The code below reviews an invented decision log from a previous project at the utility, the kind of evidence the lessons log drew on.

from datetime import date
log = [
    ("Request to initiate", date(2022, 3, 1), date(2022, 3, 9), "authorize initiation"),
    ("PID and stage 2 plan", date(2022, 6, 1), date(2022, 8, 17), "authorize project and stage"),
    ("Exception report: contractor delay", date(2022, 10, 3), date(2022, 12, 19), "exception plan approved"),
    ("Highlight report: approve a 2,000 purchase", date(2022, 11, 2), date(2022, 11, 30), "approved"),
    ("End stage report and stage 3 plan", date(2023, 2, 1), date(2023, 3, 1), "authorize stage"),
    ("Closure recommendation", date(2023, 9, 4), date(2023, 9, 12), "authorize closure"),
]
waits = [(item, (decided - raised).days) for item, raised, decided, _ in log]
for item, days in waits:
    flag = "  <-- slow" if days > 21 else ""
    print(f"{item:44} {days:3d} days{flag}")
avg = sum(d for _, d in waits) / len(waits)
print(f"Average wait: {avg:.0f} days")
micro = [i for i, *_ in log if "purchase" in i]
print("Decisions the project manager should have made:", micro)

Request to initiate                            8 days
PID and stage 2 plan                          77 days  <-- slow
Exception report: contractor delay            77 days  <-- slow
Highlight report: approve a 2,000 purchase    28 days  <-- slow
End stage report and stage 3 plan             28 days  <-- slow
Closure recommendation                         8 days
Average wait: 38 days
Decisions the project manager should have made: ['Highlight report: approve a 2,000 purchase']

Four of the six decisions waited more than three weeks, and the average wait was 38 days. The PID waited 77 days, so the project sat idle after initiation, and the exception report also waited 77 days, during which the project carried on as if nothing had happened. One decision, approving a small purchase, should never have reached the board at all; it was within the project manager's delegated authority. The lessons from this log shaped Ridgeline Water's board arrangements: decision dates planned in advance, a five-day response target for exceptions, and clear delegated limits so that small decisions stay with the project manager.

Directing and the business layer

The board is itself directed by the business layer. It must keep the business layer informed, typically through the executive, and it must refer anything beyond project tolerances upward. It also provides the business layer's interface to the project: if corporate strategy changes, or a program reprioritizes its projects, the business layer tells the board, which gives the project manager ad hoc direction. Ridgeline Water's executive reports to the general manager monthly and to council at each stage boundary, using the end stage report as the basis.

In a US municipality, the business layer's oversight often includes the city council or utility board receiving staff reports at key decisions, frequently at public meetings with agenda deadlines. Aligning PRINCE2 stage boundaries with meeting and agenda dates avoids a common delay: a stage ending just after an agenda deadline may wait a month for the next meeting.