A project can deliver its final output and still not be formally closed.
Closing consists of the actions performed to formally complete or close a project, phase, contract, or, in some cases, to terminate a project before completion. That includes verifying that specific actions from the other focus areas are actually finished before anything gets declared complete — not just checking that the deliverable shipped, but confirming the surrounding work is done too.
The Close Project or Phase process spells out what that actually involves: finalizing all activities related to the project, whether it succeeded or didn't, archiving information, releasing resources, and confirming the extent to which value — or the capability to deliver value — was achieved. None of that happens automatically once the last task gets checked off.
Table of Contents
What closure actually requires
For predictive work, satisfying exit criteria means confirming documents and deliverables are updated, issues are resolved, measurable value was delivered with a plan to sustain it, and the customer has formally accepted the work. Beyond that: project accounts close, personnel get reassigned or released, and equipment and facilities get reallocated.
Contracts follow their own sequence, and it starts with an acceptance step that functions as the sign-off: confirming formal acceptance of the external source's work. Only after that can the rest proceed — finalizing any open claims or warranties, updating records with final results, ensuring invoices are paid, archiving the records, and resolving any disputes. If acceptance hasn't happened, or a claim, invoice, or warranty is still open, the contract isn't ready to close — no matter how finished the deliverable looks.
A third layer is easy to skip because it doesn't feel urgent: auditing project records, assessing success or failure, documenting lessons learned, measuring stakeholder satisfaction, and verifying regulatory and legal obligations were actually met.
Adaptive approaches close just as deliberately, differently. Closing an iteration means confirming backlog items meet acceptance criteria, getting stakeholder sign-off, and checking nothing's outstanding. Retrospectives capture lessons before the team disperses, and any unresolved risk gets explicitly carried forward — accepted, or handed to the next iteration or operations — rather than left to disappear.
What gets lost when closure gets shortchanged
Skip the process-defined closure activities, and specific, identifiable things go missing:
Lessons learned never make it into the register, so the next project starts without them.
Resources — people, equipment, facilities — stay allocated to a project that's effectively already over.
Contractual obligations go unverified, leaving exposure nobody's actively tracking.
Stakeholder satisfaction never gets measured, so there's no confirmed answer to whether the project actually met expectations.
Outstanding risks never get a clear owner. The project's gone, but what it produced isn't — someone still needs to be watching for a risk that only shows up once the deliverable is actually in use.
What actually helps
Treat the closure list as work to finish, not a box to tick. Exit criteria, contract closeout, and the other closure tasks are three separate jobs — each needs its own check, not one sign-off covering everything.
Get formal acceptance before calling a contract closed. It comes first for a reason — everything after it assumes the work has already been accepted.
Schedule time for lessons learned and retrospectives, don't leave them to the end. By the time a project actually finishes, people forget the details that made the lesson worth capturing.
Decide what happens to every unresolved risk before the project ends. Don't let it just disappear with the team — either accept it, or hand it to whoever's taking over next.
The bigger point
Closing doesn't mean nothing's happening at the end of a project. It has its own defined process, with its own steps and outputs — just as deliberate as initiating or planning a project in the first place. It gets skipped not because it's optional, but because no deadline is pushing it forward the way one pushed everything before it.
The projects that close properly aren't the lucky ones. They're the ones where someone actually did the work, instead of leaving it half-finished because nobody was checking.
P.S. Know someone who wants to get better at project management? Share this with them.
And if you haven't already, subscribe to get practical project management insight in your inbox every Saturday: https://vandersonbaril.com/newsletter/
Thank you for reading, and see you next Saturday.
