ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Project closure is the phase everybody agrees matters and almost nobody funds. The
team has already moved on, the sponsor has stopped attending, and the closure report gets written by
one person on a Friday. That is a shame, because closure is the only point at which a project can
convert what it learned into something the next project can use.
Four things, and they are separable. Confusing them is why closure so often collapses into a single
thin document.
Note what is not on that list: proving the project was a success. Benefits usually land months
after closure, which is why the post-implementation review exists as a separate event.
Two failures account for almost all of it.
The first is that the session becomes either a celebration or a blame allocation. Both feel
productive and neither produces anything actionable. The fix is structural: run it against the
project’s own record — the RAID log, the change log, the variance against baseline —
rather than against people’s recollections. Ask which risks materialised, which assumptions turned out
false, and which dependencies slipped, because
the RAID log already holds the answers with dates
attached.
The second is that the lessons go into a report nobody reads. A lesson that does not change a
template, a checklist, an estimating assumption or a governance rule has not been learned — it
has been recorded. The test of a lessons learned process is whether anything downstream is different
because of it.
Closure asks whether the project delivered what it promised. The post-implementation review, held
months later, asks whether the thing delivered is actually working and whether the benefits in the
business case are materialising. It needs the sponsor, not the project manager, because by then the
project manager has no authority to act on the answer.
Booking the PIR at closure — with a date and an owner — is the single cheapest thing
you can do to make benefits realisation real rather than aspirational.
Thirteen closure templates, including the PIR.
The Project Management Toolkit ships 390+ editable MS Office templates. The closure set covers the project closure report and checklists, closure meeting agenda and presentation, lessons learned report, a retrospective template, post-mortem deck, project and release PIR templates, a technical handover document and knowledge transfer templates.
The practical reason closure is done badly is that nobody costed it. The plan runs to go-live, the
team is committed to the next thing from the following Monday, and closure happens in whatever gaps
people can find. Put closure in the plan as a phase with an owner, an end date and named people who
are still allocated — typically two to four weeks for a mid-sized project, more where contracts
and assets are involved. A closure phase that exists in the schedule gets done; one that depends on
goodwill does not.
| Section | What it must contain |
|---|---|
| Performance against baseline | Time, cost, scope and quality, with the variance explained not just stated |
| Deliverables and acceptance | What was handed over, accepted by whom, on what date |
| Outstanding items | Open defects and deferred scope, each with a named owner |
| Handover | Operational owner, support model, hypercare end date |
| Commercial closure | Contracts closed, final spend against budget |
| Lessons learned | What changes as a result, and who is making the change |
| PIR arrangements | Date, owner, and what will be measured |
The outstanding items row is the one to get right. Every project closes with something unfinished,
and the honest ones say so. A closure report with no open items is either a very unusual project or a
report written to look tidy.
Of the four objectives, handover is the one that fails quietly. Delivery gets confirmed because
somebody is chasing acceptance; commercials get closed because finance chases them. Handover has no
natural chaser, and the project team’s incentive is to leave.
A handover that holds needs five things in place before the team disperses:
The reason to be strict here is that the alternative is expensive in a way that never appears in
the project’s numbers. A system handed over badly generates support cost, workarounds and eventually a
remediation project — all charged to operations, none of it visible in the closure report that
declared the project a success.
There is a strong pull, at closure, to quietly finish the last few things rather than hand them
over. It feels helpful and it is a mistake: the project stays open, the budget keeps burning, and the
handover never happens because the team is still doing the work.
Transfer them instead. Every outstanding item gets a named owner outside the project, a date, and a
route into whatever backlog or change process will carry it. The closure report records that transfer.
A project that closes with six transferred items and a clean handover is in better shape than one
that stays open for three months finishing them.
When should project closure start?
Before delivery finishes. Acceptance, handover and commercial closure all take longer than expected,
and starting them at the end guarantees a drawn-out tail.
What is the difference between closure and a post-implementation review?
Closure confirms the project delivered what it promised and shuts it down. The PIR, months later,
asks whether the outcome is working and whether the benefits are arriving.
Who signs off project closure?
The sponsor or project board, on the basis of formal acceptance from whoever the acceptance criteria
named. The project manager prepares it; they do not authorise it.
What if the project is cancelled?
It still gets closed properly. A cancelled project has contracts to close, assets to recover and
— usually — more valuable lessons than a successful one.
How do we make lessons learned actually useful?
Require every lesson to name the artefact it changes: a template, a checklist, an estimating
assumption, a governance rule. Lessons that change nothing are notes, not lessons.
Project closure is cheap to do well and expensive to skip, and the cost of skipping it lands
somewhere the project’s numbers never show. Start it before delivery ends, get acceptance in writing
from the people the criteria named, transfer the outstanding items rather than absorbing them, and put
a date and an owner against the post-implementation review before the team disperses. The closure
report is worth writing honestly — open items and all — because the only audience that
matters is the project that comes after this one.
All of these are covered by the Project Management Toolkit, or start with the free ISO templates.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026