Project Management Leadership with AI · Stakeholder and team leadership · lesson 17 of 21 · 12 min

Closing projects and learning from them

Closing is a phase, not an afterthought

Many projects fade out instead of closing properly. Formal closure confirms acceptance, releases resources, closes contracts, hands over to operations, and captures lessons. It also marks the start of benefits realisation.

Closure checklist

[ ] Deliverables accepted against acceptance criteria (signed)
[ ] Handover to operations/support completed: documentation, training, support model, warranties
[ ] Outstanding issues and defects transferred with owners
[ ] Contracts closed: final payments, retentions, warranties, disputes resolved or transferred
[ ] Financial closure: final costs, accruals, budget returned or reallocated
[ ] Resources released with feedback and recognition
[ ] Records archived per retention policy (including data protection requirements)
[ ] Benefits realisation plan handed to business owners with measurement dates
[ ] Lessons learned captured and shared
[ ] Closure report approved by sponsor/board

Premature and early closure

Sometimes the right decision is to stop a project before completion because the business case is no longer valid, a better option has emerged or risks are unacceptable. Close it just as carefully: salvage reusable outputs, communicate the reasons, recognise the team's work and capture lessons. Treating cancellation as shameful discourages people from recommending it when it is right.

Lessons learned that actually change behaviour

Most lessons-learned documents are written and never read. Make them useful:

Capture continuously (retrospectives, stage-end reviews), not only at the end.
Be specific: "Vendor onboarding for payment gateways took 10 weeks, not 4; start procurement at project initiation" beats "procurement was slow".
Separate what happened, why, and what to do differently.
Assign owners to organisational changes (e.g., update the procurement checklist).
Make them findable: tag by project type, phase and topic; share in communities of practice.
Review lessons at the start of new projects, not only at the end of old ones.

Lessons template

ID | Category    | What happened                               | Root cause                      | Recommendation                              | Owner       | Status
L1 | Procurement | Payment gateway onboarding took 10 weeks    | Lead time not researched        | Add lead-time check to initiation checklist | PMO lead    | Done
L2 | Testing     | UAT delayed 3 weeks                         | Business users unavailable      | Confirm UAT availability at planning gate   | Sponsor     | Open
L3 | Team        | Early cross-site pairing improved quality   | Knowledge shared faster         | Default for distributed teams               | Delivery mgr| Adopted

Handover to operations

Operations teams inherit what projects build. Involve them early (in design and testing), agree acceptance criteria for operational readiness, and plan a hypercare period with extra support after go-live.

Post-implementation review

Some months after go-live, review whether outcomes and benefits are being achieved, whether the solution is performing as expected, and what else is needed. This review belongs to the business owner, with support from the PMO.

Worked example

Illustrative. A fictional utility company in Texas closed a meter-replacement programme. The closure report showed the programme had finished on time but with a large backlog of customer complaints about billing estimates. Instead of declaring success, the sponsor extended hypercare for billing, assigned an owner for complaint reduction, and added a lesson: "Include billing process readiness in go-live criteria for metering projects." The next programme adopted it.

Common mistakes

Team disbanded before closure activities are done.
Contracts left open, creating later disputes.
Lessons that are vague or blame-focused.
No handover of benefits measurement.

Quick self-check

Look at the last project you finished. Could a new team find its lessons within five minutes, and did any lesson change how the next project was run? If not, redesign your lessons process around those two tests.

Celebrating and transitioning people

Closure is also a human moment. Recognise contributions publicly, thank suppliers and stakeholders, and provide feedback to team members' line managers. Support people as they move to new roles; the way a project ends shapes how people remember it and whether they want to work with you again. A short, sincere celebration of what was achieved, even for a project closed early, is time well spent.

Organisational learning

A PMO or community of practice can turn project lessons into better templates, checklists and training. Review recurring themes across projects each quarter and fix the systemic causes, such as procurement lead times or unavailable testers, that individual projects cannot solve alone.

Hands-on: a lessons log that drives change (Excel)

Columns: A ID | B Observation | C Cause (after 'why?') | D Lesson (specific, causal) | E Action | F Owner | G Due
H Embed in (template / checklist / standard / training) | I Status | J Verified on next project? (Y/N)
K Quality flag  =IF(OR(C2="",E2="",F2="",H2=""),"INCOMPLETE: not a lesson yet","")
Summary: share of lessons with actions =COUNTIF(K:K,"")/(COUNTA(A:A)-1) ; actions overdue =COUNTIFS(G:G,"<"&TODAY(),I:I,"<>Done")

Template: closure checklist

[ ] Deliverables formally accepted against criteria (signed)
[ ] Benefits handed to named owners with measures, baselines and review dates
[ ] Operations acceptance criteria met; hypercare exit criteria met
[ ] Contracts closed: final invoices, retentions, warranties recorded
[ ] Finances reconciled; project cost codes closed; licences transferred or cancelled
[ ] Documentation, support guides, known issues transferred
[ ] Lessons session held; actions owned and embedded
[ ] Team recognised; people released with feedback and references
[ ] Post-implementation review scheduled (date: ____)

Prompt template: clustering lessons (approved AI tool)

Cluster the retrospective notes below into themes. For each theme, list the notes it contains verbatim, propose one
candidate root cause as a question for the team to test, and suggest where an action might be embedded (template,
checklist, standard, training). Do not assign blame to individuals or name people.

How to measure success

Every lesson has a cause, an owner, a due date and an "embed in" location.
Lessons verified as applied on the next project.
No open contracts, cost codes or licences three months after closure.

Video lecture: Closing projects and learning from them

Lecture coming soon · 10 chapters · about 8 minutes. Read the full transcript below.

Closing is a phase, not an afterthought
Why it matters
The concept: a closure checklist
Handover to operations and early closure
Worked example one: turning an observation into a lesson
Worked example two: meter replacement in Texas
Watch me do it: a 45-minute lessons session
Organisational learning
Post-implementation review, people and common mistakes
Recap and try this now

Lecture transcript

Closing is a phase, not an afterthought

A utility company in Texas, fictional, finished a large meter-replacement programme on time. The closure report was ready to declare success. Then someone looked at customer complaints: there was a large and growing backlog about estimated bills. The meters were installed, but the billing process hadn't been ready for them. Declaring victory would have been easy. The sponsor did something better. In this lecture you'll learn why closing deserves as much discipline as starting, what a closure checklist covers, how to hand over properly to operations, how to run lessons learned that actually change behaviour, what a post-implementation review is for, and how to transition people well. By the end, you'll be able to run a forty-five-minute lessons session whose recommendations actually get implemented.

Why it matters

Why does closing matter? Because loose ends cost money: contracts left open, licences still billing, resources still charging to the project. Because operations inherits whatever the project leaves behind, and a poor handover turns into a support burden and unhappy users. And because organisations that don't capture and act on lessons repeat the same mistakes, project after project. There's also a human reason. People remember how a project ended. A rushed, silent close, with people scattered to new work without recognition, leaves a very different memory from a well-run close that celebrates what was achieved and helps people move on well.

The concept: a closure checklist

Here's what closure covers. Formal acceptance of deliverables against their criteria. Benefits handed over to their business owners, with the measures and review dates agreed. Contracts closed, with final invoices, retentions and warranties recorded. Finances reconciled and project cost codes closed, so nothing keeps charging. Resources released, with thought given to where people go next. Documentation and knowledge transferred: support guides, configuration records and known issues. Lessons captured, and turned into actions. And the team recognised. Think of it like moving out of a rented flat. You don't just walk out. You clean, fix, hand back the keys, close the utility accounts and get the deposit back. Skip those steps, and the bills keep arriving.

Handover to operations and early closure

Handover to operations deserves special care. Agree operational acceptance criteria early, not in the final week: what support, documentation, monitoring and training operations needs before it takes ownership. Then plan a hypercare period, perhaps several weeks, when the project team stays close to fix early problems, with clear exit criteria such as incident volumes falling below a threshold. And sometimes projects close early, because the business case no longer holds, or a strategy changes. Closing early isn't failure. Continuing a project that no longer makes sense is. When you close early, close well: stop spending, record what was delivered and what wasn't, release people, and capture lessons, because early closures are often where the richest lessons are.

Worked example one: turning an observation into a lesson

Let's turn a weak lesson into a strong one. The retrospective notes say: 'testing was rushed'. That's an observation, and it won't change anything. Ask why. The test environment arrived five weeks late. Why? Because the infrastructure team was only engaged after the build started. Now we have a lesson: engage infrastructure during planning, because environment lead times can exceed five weeks. And then the most important step, which most organisations skip: an action with an owner, a date and a place where it will be embedded. For example: the PMO adds 'request test environments' to the planning checklist, by the thirtieth. A lesson that doesn't change a checklist, a template, a standard or a habit isn't learned. It's just recorded.

Worked example two: meter replacement in Texas

Back to the fictional Texas utility. The meter-replacement programme finished on time, but with a large backlog of customer complaints about estimated bills. Instead of declaring success and moving on, the sponsor extended hypercare specifically for billing, assigned a named owner for reducing complaints, and added a lesson: include billing process readiness in the go-live criteria for metering projects. The next programme adopted it. Notice what made this work. The sponsor looked at outcomes that mattered to customers, not just outputs like meters installed. The lesson was specific and actionable. And it was embedded into the criteria the next programme would actually use. That's organisational learning, as opposed to a lessons document nobody opens again.

Watch me do it: a 45-minute lessons session

Let me walk you through the forty-five-minute session I run. Five minutes: together, we build a quick timeline of key events on a whiteboard, which refreshes memories and anchors the discussion in facts. Fifteen minutes: everyone writes silently on sticky notes, what helped and what hindered, then we share and cluster them. Silent writing first stops the loudest voice from dominating. Fifteen minutes: we vote on the top three clusters and ask 'why' until we reach causes we can act on. And ten minutes: for each, an action with an owner, a date, and, crucially, where it will be embedded: a template, a checklist, a standard or a training session. I publish the output within a day and review progress on the actions a month later.

Organisational learning

Individual lessons only become organisational learning when someone curates them. A lessons database with thousands of entries nobody reads is not learning. It's archiving. A good PMO does three things. It looks for patterns across projects, because a lesson that appears in five closure reports is telling you something about the organisation, not about one team. It turns those patterns into changes to templates, checklists, standards and training, so the next project benefits without having to search for anything. And it makes it easy to start a new project by reading what similar projects learned, for example a one-page 'top ten lessons for projects like this' used at every kickoff. An approved AI assistant can help here, by clustering lessons across many reports and drafting summaries for review, but the decision about what to change in the standards stays with people who own those standards.

Post-implementation review, people and common mistakes

A post-implementation review, usually a few months after go-live, asks different questions from a retrospective. Were the benefits realised against the baselines in the business case? Is the solution working well in real use? What would we do differently in the next investment? It closes the loop on the business case. Then people. Celebrate what the team achieved, recognise specific contributions, and support people's transitions to their next roles, including honest references and feedback. The common mistakes: lessons sessions that turn into blame, generic lessons like 'communicate better', lessons with no owners or actions, and skipping formal closure entirely because everyone has already moved on to the next urgent thing.

Recap and try this now

Let's recap. Closing is a phase that deserves discipline: formal acceptance, benefits handed to owners, contracts and finances closed, resources released, knowledge transferred and a planned handover with hypercare. Close early projects well, too. Lessons learned only count when they're specific, based on causes, and turned into owned actions embedded in templates, checklists or standards. A post-implementation review checks whether benefits were realised. And people deserve a good ending: recognition, celebration and support for what comes next. Your try-this-now: run a forty-five-minute lessons-learned session on a recent project using the agenda from the lesson, and assign an owner, a date and an 'embed in' location to each recommendation.

Key takeaways

Formal closure confirms acceptance, hands over, closes contracts and finances, and captures lessons.
Stopping a project early can be the right decision; close it carefully and without blame.
Useful lessons are specific, root-caused, owned, findable and reviewed at the start of new projects.
Plan handover and hypercare with operations; business owners run post-implementation reviews.

Try it

Run a 45-minute lessons-learned session on a recent project using the template, and assign an owner to each recommendation.