Closing and lessons learned

Why it matters

When the product launches, most teams want to move on. But projects that just fade out leave problems behind: deliverables nobody formally accepted, support staff who do not know how the system works, contractor invoices still open, and the same mistakes repeated on the next project. Closing turns a launch into a finished project, and a lessons-learned review turns experience into improvement.

The closing checklist

A practical closure list for the food bank site:

1. Formal acceptance. The sponsor confirms each deliverable meets its acceptance criteria from the scope statement, in writing (an email is fine for small projects). "A volunteer can sign up on a phone in under 2 minutes: tested with 5 volunteers, average 1 minute 20 seconds."
2. Handover to operations. The people who will run and support the result get what they need: access, documentation, a walkthrough, and a named contact. Here, the IT volunteer receives the hosting login (through a password manager, never by email), the handover notes and a one-hour session.
3. Close contracts and finances. Pay final invoices, cancel trial accounts and tools you no longer need, return equipment, and record the final cost against the budget.
4. Release the team. Tell people and their managers when their time on the project ends. Thank them, and give feedback for their reviews.
5. Archive. Store the final scope, schedule, risk register, decisions and lessons learned where future teams can find them.
6. Celebrate. Mark the finish. It matters for morale and for the next project.

If a project is cancelled early, close it too. Documenting why it stopped is often the most valuable lesson of all.

Lessons learned

A lessons-learned review (also called a retrospective or post-project review) asks what went well, what did not, and what to do differently. It works only if it leads to changes, and only if people feel safe being honest.

Make it blameless

The aim is to improve the system (processes, tools, communication), not to find someone to blame. Assume everyone did the best they could with what they knew at the time. If people fear blame, they hide the very problems you need to learn from. Agree this explicitly at the start.

A simple 60-minute format

1. Set the stage (5 min). Purpose, the blameless rule, the timeline of the project on a wall or screen.
2. Gather data (15 min). Everyone writes sticky notes silently in three columns: Went well, Did not go well, Puzzles (surprises or open questions). Include stakeholders such as the sponsor or support team, or gather their input beforehand with a short survey.
3. Group and vote (10 min). Cluster similar notes into themes; each person gets three votes for the themes that matter most.
4. Dig into the top themes (20 min). For each, ask why it happened. A short "five whys" chain helps reach a root cause:

Design was 4 days late.
  Why? Photos arrived late.
  Why? The request went out in mid-January.
  Why? Nobody owned asking for content.
  Why? Content was not in the WBS.
Lesson: put "content collection" in the WBS with an owner and a deadline.

5. Actions (10 min). Turn each top theme into a specific action with an owner and a date: "Add a Content work package to our WBS template (Sam, by 15 April)." A lesson without an action is just a complaint.

Keep what went well

Successes are lessons too. "Usability testing on paper prototypes caught three problems before build" should become a standard step on the next project.

Share them

Write a one-page summary: what happened, top lessons, actions. Store it with other projects' lessons, and read the lessons from similar projects when you start a new one. That is the step most organisations skip.

Agile teams run small retrospectives every sprint rather than only at the end, which is why they improve quickly. You can do the same on any project: a 15-minute review at each phase gate or milestone.

Common mistakes

• Skipping formal acceptance, so "finished" is disputed later.
• Handover by email only, with no walkthrough.
• Forgetting to cancel paid tools and trials, which keep charging.
• Blame-focused reviews, so people stay silent.
• Lessons with no owner or action, filed and forgotten.

Quick recap

• Close with formal acceptance, handover, contract and finance closure, team release, archiving and a celebration.
• Run a blameless lessons-learned review: gather, group, find root causes, agree actions with owners.
• Capture what went well too, share the summary, and read past lessons before starting new projects.

Try it

Open the Do tab and run a lessons-learned review on a project you have finished, at school, work or home.