Initiating a project II: controls, the project plan and the refined business case

With tailoring agreed and the management approaches drafted, the project manager turns to the three products that give the board its main evidence when it decides whether to authorize the project: the project controls, the project plan and the detailed business case. They are developed together, because each depends on the others. The controls define the stages and tolerances that the plan must respect; the plan supplies the costs and timescales the business case needs; and the business case determines whether the plan is worth executing at all.

Set up the project controls

Project controls are the arrangements that let each level of management monitor and control the level below. In plain terms, they answer five questions. How is the project divided into management stages, and where are the decision points? What tolerances apply at each level? What reports will be produced, by whom, how often and for whom? How will exceptions and issues be escalated? And how will the project's records be kept and its lessons captured? The answers come partly from the business layer, partly from the board's preferences and partly from the management approaches.

Stage boundaries deserve care. They should fall where a real decision can be made with new information: after the pilot, when the leak benefit can be measured; after the first rollout group, when installation rates are known. They should also fit external constraints, such as council approval cycles. PRIN-130 covered the factors in choosing stages; in initiation those choices become firm controls in the PID.

Allocating tolerances between levels

Tolerances must nest. Stage tolerances should leave room within project tolerances, so that one bad stage does not automatically breach the whole project. The project manager proposes, and the board agrees, how much of the project's tolerance each stage may use. The code below checks Ridgeline Water's proposed allocation: each stage's upper cost tolerance in thousands, added up, should not exceed the project's cost tolerance, and the board should keep some project tolerance in reserve.

project_budget = 9600
project_tol_pct = 0.05
stages = {  # name: (budget, upper cost tolerance as a fraction)
    "1 Initiation": (160, 0.10),
    "2 Pilot": (1450, 0.05),
    "3 Rollout 2-8": (3700, 0.04),
    "4 Rollout 9-20": (4290, 0.03),
}
project_tol = project_budget * project_tol_pct
used = 0.0
print(f"{'Stage':16} {'Budget':>7} {'Tol %':>6} {'Tol $000':>9}")
for name, (budget, tol) in stages.items():
    amount = budget * tol
    used += amount
    print(f"{name:16} {budget:7,} {tol*100:5.1f}% {amount:9.1f}")
print(f"Sum of stage tolerances: {used:.1f} of project tolerance {project_tol:.1f} thousand")
print(f"Unallocated reserve at project level: {project_tol - used:.1f} thousand ({(project_tol - used) / project_tol:.0%})")
print("Allocation acceptable:", used <= project_tol)

Stage             Budget  Tol %  Tol $000
1 Initiation         160  10.0%      16.0
2 Pilot            1,450   5.0%      72.5
3 Rollout 2-8      3,700   4.0%     148.0
4 Rollout 9-20     4,290   3.0%     128.7
Sum of stage tolerances: 365.2 of project tolerance 480.0 thousand
Unallocated reserve at project level: 114.8 thousand (24%)
Allocation acceptable: True

The four stage tolerances add up to about 365 thousand out of a project tolerance of 480 thousand, leaving about 115 thousand, or 24 %, unallocated. That reserve gives the board room to absorb a stage exception without immediately referring the project to the business layer. Note that the percentages differ: initiation has a large percentage but a small amount, and the later rollout stages, which are larger and better understood after the pilot, have smaller percentages. Rollout tolerances are provisional and will be confirmed at each stage boundary.

Create the project plan

The project plan is a high-level plan for the whole project. It shows the major products, the management stages and their boundaries, the main activities and resources, the costs and timescales, and the key dependencies, both internal and external. PRIN-130 described how plans are built with product-based planning; in initiation, the project manager applies those techniques to the whole project at a level of detail suitable for the board. The first delivery stage will be planned in more detail during managing a stage boundary at the end of initiation.

The project plan also refines the project product description from starting up, with the senior user confirming the acceptance criteria now that more is known. For Ridgeline Water, initiation's coverage survey and supplier engagement allow the plan to show realistic installation rates, network build times and costs, and the billing interface workshop allows the plan to show the dependency on IT's upgrade explicitly, with a date by which the upgraded interface must be available.

Refine the business case

The outline business case from starting up becomes the detailed business case. The executive remains accountable, with the project manager typically drafting. It now uses the project plan's costs and timescales, the refined benefits from the senior users, the major risks from the risk register and an updated investment appraisal. It must answer the question the board will ask at the end of initiation: is the whole project worth doing, and is it still the best option? The benefits management approach is finalized at the same time, so that the business case's benefits can be measured.

For Ridgeline Water, the most important refinement concerns the leak benefit. Initiation's leak data analysis estimates current non-revenue water more precisely, and the pilot stage is designed to measure how customers respond to alerts. The detailed business case therefore states clearly that the decision to roll out will be revisited at the end of the pilot, with a threshold: if measured leak savings fall below about 70 % of forecast, rollout should be reconsidered. This links the business case, the stage structure and the board's decision at week 37.

For a Canadian municipal utility, the detailed business case may also need to follow provincial asset management planning rules where they apply, such as Ontario's regulation on asset management planning for municipal infrastructure, and the municipality's own capital budgeting policies. Federal infrastructure funding programs, where used, bring their own reporting requirements.

How the three products fit together

Controls, plan and business case are developed iteratively. A first draft of the plan may show costs that weaken the business case, prompting a change of approach; a tolerance allocation may show that the plan has too little contingency; a benefits profile may suggest moving a stage boundary so that a benefit can be measured before the next commitment. Initiation's job is to bring them into agreement and to make the remaining uncertainties visible to the board.

Reporting arrangements in the controls

The reporting part of the project controls deserves as much care as the tolerances, because reports are how the board knows whether to intervene. The controls should say, for each report, who produces it, who receives it, how often or on what event, what it must contain and how quickly it must be acted on. They should also say how reports are delivered: a highlight report sent as a short email with a link to the project tool may be read; a 20-page document attached to a meeting invitation often is not.

Look at the last row. PRINCE2's reports serve the project's levels of management, but public organizations often have their own reporting obligations, such as staff reports to council or a board of directors. Recording them in the controls avoids duplicated effort: the end stage report can be written so that it becomes the basis of the staff report, instead of the project manager producing two different accounts of the same stage.