Closing a project II: evaluation, lessons and premature closure

Once the products are accepted and handed over, the project manager evaluates the project and recommends closure. The evaluation is recorded in the end project report, which tells the board how the project performed against its original intentions and its approved changes, whether the business case still holds, what the team learned and what still needs doing. The board then authorizes closure in directing a project and notifies the business layer. This lesson follows those steps for Ridgeline Water, then looks at the harder case: closing a project that has been stopped before it finished.

Evaluating the project

Evaluating the project means comparing what happened with what was planned, at project level. The project manager uses the baselines in the project initiation documentation, as amended by approved changes and exception plans, and asks: did the project deliver the agreed products, at what cost, in what time, to what quality, with what risks, and with what effect on the business case? The evaluation is honest about both successes and failures. It also reviews how the team and the management approaches performed, because those lessons are as valuable as the results.

stages = {  # stage: (baseline, actual) in thousand
    "Initiation": (160, 158),
    "Pilot": (1450, 1581),
    "Rollout stage 1": (3700, 3846),
    "Rollout stage 2 and closure": (4290, 4318),
}
base = sum(b for b, a in stages.values())
act = sum(a for b, a in stages.values())
tol_cost = base * 0.05
for k, (b, a) in stages.items():
    print(f"{k:28} baseline {b:6,}  actual {a:6,}  variance {a - b:+5,}")
print(f"project: baseline {base:,}  actual {act:,}  variance {act - base:+,}  cost tolerance used {(act - base) / tol_cost:.0%}")
end_base, end_act, tol_time = 100, 101, 8
print(f"time: baseline week {end_base}, actual week {end_act}, time tolerance used {(end_act - end_base) / tol_time:.0%}")

Initiation                   baseline    160  actual    158  variance    -2
Pilot                        baseline  1,450  actual  1,581  variance  +131
Rollout stage 1              baseline  3,700  actual  3,846  variance  +146
Rollout stage 2 and closure  baseline  4,290  actual  4,318  variance   +28
project: baseline 9,600  actual 9,903  variance +303  cost tolerance used 63%
time: baseline week 100, actual week 101, time tolerance used 12%

The project cost 9,903 thousand against a baseline of 9,600 thousand, using about 63 % of the 480 thousand cost tolerance, and finished at week 101, using one of its eight weeks of time tolerance. Two exceptions, one in the pilot and one in rollout stage 1, account for most of the cost variance, and both were decided by the board within project tolerances. That is a respectable result for a project of this size and uncertainty, and the end project report says so plainly, alongside what it cost and why.

The end project report

The end project report is the project manager's account of the project for the board. It is the counterpart, at project level, of the end stage report, and it replaces the end stage report for the final stage. It usually carries the project manager's recommendation that the board authorize closure.

Benefits after closure

Most benefits arrive after a project closes. Ridgeline's leak savings build year by year as the network team uses the data; billing savings arrive as estimated bills disappear; customer service improves as complaints fall. The project cannot measure benefits that have not happened yet, so closing a project updates the benefits management approach to say how and when the remaining benefits will be measured, by whom, and how results will be reported. Responsibility for those reviews sits with the executive, on behalf of the business layer, not with the project manager, whose role ends at closure.

Capturing and passing on lessons

Closing a project reviews the lessons log and decides which lessons should be passed on. A lessons report goes to the people who can act on them: the corporate project office, the asset management team, the procurement team. Ridgeline's most valuable lessons were about using a pilot to test the biggest assumptions, surveying site conditions before planning installation rates, and assessing legacy data before committing to interfaces. The project office built two of them into the utility's project templates.

Recommending and authorizing closure

When the products are handed over, the evaluation is complete and the follow-on actions have owners, the project manager recommends closure to the board, usually with a draft closure notification. The board performs its last directing activity, authorizing project closure. It reviews the end project report, confirms that the products have been accepted and handed over, checks that the benefits reviews are planned and the follow-on actions owned, and then authorizes closure. It sends a closure notification to the business layer and to anyone else who needs to know, such as suppliers, support teams and finance, and the project's resources are released. The project records are archived for audit and for future projects.

Ridgeline Water's project records are kept under the municipality's records retention bylaw. Contract and financial records, including holdback releases, are kept for the periods the bylaw and provincial limitation rules require, and the archived file is indexed so that a future project manager can find the lessons and the as-built data.

Premature closure

Not every project reaches its planned end. The business case may collapse, the organization's priorities may change, a better solution may appear, or an exception may show that the project cannot be recovered within any acceptable limits. When the board decides that a project should stop, it instructs the project manager to close it prematurely. Closing a project then starts with preparing premature closure instead of preparing planned closure.

Ridgeline Water had a small example. Alongside the smart meter project, the utility had started a separate customer portal project to give customers online access to their consumption and bills. During rollout stage 1, the billing system vendor announced that its next release would include a customer portal with most of the same features, at no extra licence cost. The portal project's board looked at its updated business case and concluded that building its own portal was no longer justified. It instructed premature closure.

Premature closure is still controlled closure. The project manager does not simply stop work. Partly built products are reviewed to see what can be used, made safe or archived; anything handed over is formally accepted; follow-on actions are recorded; and an end project report explains why the project stopped and what was gained and lost. Managing a stage boundary is not performed, because there is no next stage. The board authorizes closure in the same way as for a planned closure.

Stopping is a legitimate outcome

A project that stops because its justification has gone has not failed; it has done what PRINCE2's principle of continued business justification asks. Continuing would have spent money for no return. The failure would be to carry on because the work had started, or because nobody wanted to admit the change in circumstances. The customer portal board stopped early, salvaged the most useful products and released two developers to work that mattered more. The money it did not spend is a real saving, and the end project report records it as one.

Who does what at the end

Closure involves every level of management, and exam questions often test the division of work. The project manager prepares closure, hands over products, evaluates the project and recommends closure. Team managers complete their final work packages and contribute lessons. Project assurance checks the acceptance evidence and the end project report on the board's behalf. The senior user confirms acceptance and, with the executive, owns the benefits reviews. The senior supplier confirms that the supplier side has delivered and can be released. The executive leads the board's decision to authorize closure and ensures the business layer is notified. Project support archives the records.

One question deserves special care: who decides that a project should close early? The project manager can recommend it, for example in an exception report that lists premature closure as an option, but only the board can decide, and if the decision affects commitments above the board, the business layer may need to be consulted. A project manager who simply stops work because the business case looks weak has taken a decision that was not theirs.