Closing a project I: planned closure, handover and acceptance

Every project should end on purpose. A project that simply fades away, with the team drifting to other work and the products half handed over, leaves the organization paying for loose ends: products nobody supports, costs still charged to the project, benefits nobody measures. Closing a project is the PRINCE2 process that brings a project to a controlled end. It confirms that the products have been accepted, hands them over to the people who will use and support them, evaluates the project, and recommends closure to the board. This lesson covers planned closure and handover. Lesson 11 covers evaluation, lessons and the special case of premature closure.

When closing a project starts

Closing a project is part of the final stage. It is triggered when the project manager, reviewing the stage status in controlling a stage, sees that the project end is approaching. It replaces managing a stage boundary at the end of the final stage, because there is no next stage to plan. It can also be triggered at any time by the board's instruction to close the project prematurely. In both cases, the project manager prepares closure, but only the board can authorize it.

Ridgeline Water's final stage

Ridgeline Water's final stage, rollout stage 2, ran from week 71 to week 101. After the exception plan in rollout stage 1, the project manager built a materials survey into the stage plan, and the crews installed meters in the newer subdivisions at a realistic rate from the start. The stage also included the work that only makes sense at the end: retiring the manual meter-reading routes, completing the hourly data reports for customers, finishing the operating procedures, and preparing the support arrangements that operations would need after the project. The project manager started closing the project at week 96, when the last installations were in sight.

Preparing planned closure

Preparing planned closure answers a simple question: has the project done what it was set up to do? The project manager updates the project plan with the actual results of the final stage, checks the product register to confirm that every product has been approved, and confirms that the users and those who will support the products have accepted them. The acceptance criteria in the project product description, agreed in initiation, are the test. Where a criterion has not been fully met, the shortfall must be visible: either it was accepted with a concession, or it becomes a follow-on action.

The code below performs the acceptance check from the product register's summary data. It is the same logic the project manager used in receiving completed work packages, applied to the project's final product.

accounts = 40008
on_smart = 39688
refused = 320
criteria = [  # name, actual, target, comparison
    ("share of accounts on smart meters", on_smart / accounts * 100, 99.0, ">="),
    ("daily read rate %", 98.6, 98.0, ">="),
    ("billing error rate %", 0.04, 0.10, "<="),
]
for name, actual, target, op in criteria:
    ok = actual >= target if op == ">=" else actual <= target
    print(f"{name:34} {actual:6.2f} vs {op} {target:5.2f}  {'met' if ok else 'NOT MET'}")
print(f"accounts not converted: {accounts - on_smart} ({refused} refused access)")

share of accounts on smart meters   99.20 vs >= 99.00  met
daily read rate %                   98.60 vs >= 98.00  met
billing error rate %                 0.04 vs <=  0.10  met
accounts not converted: 320 (320 refused access)

All the measurable criteria are met. The 320 properties where owners refused access are a known shortfall. The board accepted them as a concession at the rollout stage 2 boundary planning, because the utility, not the project, has the tools to deal with them over time. They become a follow-on action, described below.

Handing over products

Handing over is not simply delivering a final batch of products. Ridgeline handed most products over in phases: the pilot district at week 38, each rollout area as it went live. Closing a project checks that every handover is complete and properly accepted, and that the organization is ready to run the products without the project. That means the operations and maintenance arrangements are in place: support teams trained, procedures approved, spare parts stocked, warranties and contracts transferred, records and documentation filed where operations can find them.

The senior user and the senior supplier play key parts. The senior user confirms that the users have accepted the products and that the benefits can now be realized. The senior supplier confirms that the supplier side has delivered, that warranties and support obligations are clear, and that the supplier's resources can be released. Project assurance checks that the acceptance evidence is complete, rather than taking it on trust.

Ridgeline Water's finance team records the smart meters and collector network as tangible capital assets under Canadian public sector accounting standards, using the project's cost records and the as-built data from the product register. The asset management team adds them to the asset register with their installation dates and expected lives, which feeds the municipality's asset management plan.

Follow-on action recommendations

Not everything ends neatly when a project closes. Some work is left over, some issues are still open, some risks will continue to affect the products in operation, and some ideas emerged too late to include. Rather than lose them, the project manager records them as follow-on action recommendations, usually in the end project report, and passes each one to the person or group that should own it after closure. Each recommendation should say what needs doing, why and who should take it on.

Releasing resources and closing the books

Closing a project also means releasing what the project used. Team members return to their line roles, contractors' engagements end, offices and equipment are returned, and the project's cost codes are closed so that no further costs can be charged to it. These are practical steps, but they matter: a project left open in the finance system attracts costs that belong elsewhere, and a project team never formally released is still, in a sense, waiting for instructions. At Ridgeline, the project manager agreed a date with finance to close the cost codes one month after the board's closure decision, to allow final invoices and holdback or retainage releases to be processed.

Closure in agile and phased projects

Projects that deliver in releases, like Ridgeline's rollout areas or an agile product team's releases, have usually handed most products over long before the final stage. That does not make closing a project less important; it changes its emphasis. Instead of a single large handover, preparing planned closure checks that every earlier handover was properly accepted and that nothing was left in limbo between the project and operations. For an agile team, it also means agreeing what happens to the remaining backlog. Items that were never delivered are not simply abandoned: those still wanted are passed to operations or to a future project as follow-on actions, and the rest are explicitly dropped, so that nobody later assumes they were delivered.