Closing a Project Properly Still Matters
By the time a project reaches closure, the people who could close it well have usually been moved onto something else. The project manager is part-allocated to the next thing, the specialists who knew why a decision was taken have rolled off, and what is left gets treated as paperwork somebody will get to. Closure is the point where a project stops being a project and becomes somebody's responsibility to run, and doing it badly is expensive in ways that only show up later.
Effective closure has a short list of jobs. Confirming that what was built has been accepted against the criteria agreed for it. Transferring it to the people who will operate it. Settling the money and the contracts. Making the knowledge usable. Handing on whatever risk is still open. None of that is ceremonial, and most of it cannot be done retrospectively.
What closure is protecting
The Closing Focus Area, Section 4.5.5 of The Standard for Project Management, is where a project establishes that what it built has been accepted, has passed to someone who will run it, and has been settled commercially. Read that as a set of transfers. Something changes hands at closure: custody of an asset, accountability for a service, liability under a contract, ownership of a benefit that has not arrived yet.
Benefits are the transfer missed most often. A project delivers a capability, and the benefit arrives months later, when people have changed how they work. Where nobody is named as accountable for that benefit at closure, and no measurement continues past the final report, the organisation loses its ability to say whether the investment worked. The cost of that lands on the next business case, which has to be argued without evidence from this one.
Acceptance is narrower than people think
Acceptance is a decision made by a named person against criteria agreed in advance, and it covers the thing that was specified. Teams routinely fold three other questions into it: whether the deliverable works, whether the users are pleased, and whether the operations team is ready. A system can be accepted and unusable on the Monday, because acceptance tested the specification and nobody tested the shift pattern.
Transition is the separate job, and it asks whether the people who now own the thing can run it: whether they have been trained, whether they hold the access and the licences, whether the support arrangement is live, whether they know who to call at three in the morning. On a physical asset this is concrete and hard to fudge. On a service it is easy to wave through. The question worth asking at every closure is what happens the first time something goes wrong, and whether the answer still involves anyone from the project.
The parts that get skipped
Financial and procurement closure get deferred because they are nobody's favourite and they rarely block anything visibly. Open purchase orders sit against a cost centre with no owner. A supplier's final account is disputed by a project manager who has gone. Retention money stays unclaimed. None of it is dramatic, and the cumulative effect across a portfolio is a finance function that cannot say what anything actually cost.
Open risks are the second. A project ending with items still on its risk register has to put them somewhere, and there are two honest destinations: closed with a recorded reason, or transferred to the operational owner with the response attached and a named person to act on it. Leaving them in a register nobody will open again is how a known risk turns into a surprise.
A council replaced its case management system for housing repairs. The build went well, acceptance was signed on schedule, and the project closed six weeks later with a well-attended lessons session. Nine months on, the service manager could not say whether the promised reduction in repeat visits had happened, because the measure had lived in the project's reporting pack and stopped when the pack stopped. Two of the original suppliers were still drawing a support fee nobody had reviewed. The risk about data quality in the migrated tenancy records, which the project had accepted with a plan to clean it up in operation, had no owner, and the cleanup had not started.
None of those failures happened at closure. They happened because closure was treated as a set of meetings to hold, and the transfers underneath the meetings were never made. Closing that project properly would have taken an extra fortnight and named four people.
Closing in iterative and hybrid work
Iterative delivery closes more often and more quietly. A release closes, an increment closes, a funding envelope closes, and eventually the product settles into a steady state or the team is stood down. The transfers still have to happen. They are smaller and more frequent, and the risk is that none of them feels big enough to trigger a conversation about ownership. A product team running for three years may never have formally handed anything to anybody, which is comfortable right up to the week it is disbanded.
Hybrid delivery closes in pieces at different times, and that is where closure problems on large programmes usually begin. The infrastructure workstream completes and its contractors demobilise while the service workstream is still iterating. The programme carries on, so nobody treats the infrastructure end as a closure, and the as-built records, spare parts arrangements and warranty terms sit with a team that has left the building. Naming the closure of each stream, with its own acceptance and its own transfers, costs very little at the time it happens.
Knowing which of those transfers a given closure genuinely needs, and which are ceremony that can be dropped, is a judgement a structured PMP exam preparation course gives real weight to, because the gap between a project that has finished delivering and a handover that has not finished happening is where most closures actually sit.
For a PMP® candidate, the thing to spot is a situation where the work is complete and accountability has not moved. Asking who now holds each obligation is the quickest way to find that gap, because the temptation on paper and on a live project alike is to leave the project team carrying something an operational owner should have taken.
A closure list drafted while the plan is still being built is the cheapest version of all this. Write down who will accept the work, who will own it afterwards, which contracts have to be settled, what will still be measured once the team has gone, and who holds anything left open. Most of those names are known early. Closure then becomes the confirmation of arrangements that already exist, which takes days, and the fortnight of archaeology never has to happen.
Interested in going further?
Closure is the part of a project most likely to be delegated and least likely to be planned, and the transfers that genuinely matter are hard to identify from inside a project already winding down. Omega's PMP® Exam Preparation covers closing across predictive, iterative and hybrid delivery, including the handovers that happen long before a project ends.
Anyone facing a difficult handover will find the closure material in the PMBOK® Guide Eighth Edition worth an evening.
Ad · Amazon affiliate link.
References
A073: Executing in an Adaptive Project
A072: Planning in Predictive and Agile Projects
A007: The Standard for Project Management vs the PMBOK Guide
A071: Initiating Is Not Just Something You Do Once
A074: Monitoring and Controlling Without Micromanaging
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
