Project closure checklist: how to close a project and capture lessons learned

What project closure means

Closure is a phase, not a date. It starts when the last deliverable is ready for acceptance and ends when the project has no open obligations: no unpaid invoices, no unowned products, no team members still charging time to it.

The PMBOK Guide and PRINCE2 both treat closing as a deliberate set of steps. The reasons are practical. Without formal acceptance, a client can keep adding requests. Without a handover, nobody supports the product. Without a financial close, costs keep landing on a budget that nobody watches. And without lessons learned, the next project repeats the same problems.

Projects can also close early, when the business case no longer holds. An early closure follows the same checklist; it is a sound decision, not a failure.

The project closure checklist

1. Acceptance

• Confirm every deliverable against the agreed acceptance criteria.
• Get written sign-off from the sponsor or client.
• Record any accepted defects or open items with an owner outside the project.

2. Handover

• Transfer the product to the operations or support team, with documentation and training.
• Agree the warranty or support period, and who handles requests during it.
• Transfer licences, accounts, keys and access rights to their long-term owners.

3. Financial and contract close

• Receive and pay final supplier invoices; release retentions when conditions are met.
• Close purchase orders and contracts formally.
• Close the cost codes so nothing else can be charged to the project.
• Record the final cost against the baseline budget and explain the variance.

4. Records

• Archive the final schedule, cost records, risk register, issue log, change log and key decisions.
• Close or transfer every open risk and issue.

5. People

• Release team members formally and tell their line managers.
• Give feedback on each person's contribution.
• Thank the team and stakeholders in public.

6. Lessons learned

• Hold the review before people leave, and publish the actions.

How to run a lessons learned session

1. Schedule it within two weeks of handover, while memories are fresh and the team is still reachable.
2. Prepare the facts first: baseline vs actual finish date, baseline vs actual cost, the change log and the risks that occurred. Facts keep the discussion on events, not opinions.
3. Set the rule: discuss what happened and why, not who is to blame. People share real problems only when it is safe to do so.
4. Ask three questions for each phase: what went well, what did not, what should we do differently next time?
5. Group the answers into themes such as estimating, suppliers, communication, requirements.
6. Turn each theme into an action with an owner, for example "add a supplier lead-time check to the planning template". A lesson without an action is just a story.
7. Publish the record where the next project manager will find it, not only in the project folder.

Closing a project early

Sometimes the right outcome is to stop. The market changed, a regulation removed the need, or the forecast cost now exceeds the benefit. A project that is closed early still needs a proper close:

• Get a written decision from the sponsor that states the reason.
• Decide what happens to partly finished deliverables: hand over, archive or discard.
• Check supplier contracts for cancellation terms before telling suppliers, and agree final payments.
• Record what was spent, what was delivered, and what value can still be used.
• Run a lessons learned review. Early closures often teach the most, especially about the business case and how it was checked during the project.

Lessons learned record template, with an example

Here is how the record might look for a product launch that finished three weeks late and $18,000 over a $240,000 budget (7.5% over: 18,000 / 240,000 = 0.075).

Theme	What happened	Effect	Action for next time	Owner
Suppliers	Packaging supplier needed six weeks, not the four we assumed	Launch moved 2 weeks	Confirm lead times in writing before baselining	Procurement lead
Scope	A second language version was added mid-project through a change request	$12,000 and 1 week, approved	Ask about language versions at kickoff	PMO
Estimating	Photo shoot costs were estimated from an old quote	$6,000 over	Refresh quotes older than six months	Marketing lead
Went well	Weekly 20-minute check-ins kept issues visible	Issues closed faster	Keep the format in the launch template	PMO

Notice that the record explains the full variance: $12,000 + $6,000 = $18,000 of cost, and 2 + 1 = 3 weeks of delay.

Common closure mistakes

• Letting the project fade out. The team drifts away, the last 5% never finishes, and the cost code stays open for months.
• Verbal acceptance. "Looks good" in a meeting is not sign-off. Get it in writing against the criteria.
• Lessons learned as a blame session. People defend themselves and the real causes stay hidden.
• Lessons nobody reads. A document filed in a closed project folder changes nothing. Feed the actions into templates, checklists and estimating data.
• Open risks left behind. Some risks outlive the project (warranty claims, for example). Transfer them to an owner who will still be there.

How to do this in Critova

In Critova, the facts for the closure review are already in one place: the saved baselines show planned vs actual dates, cost entries show the final cost against budget, and the change request log shows every approved change with its budget and date impact. Close or reassign remaining items in the risk register and issue log, then export the registers to Excel or CSV for the archive. Feed your lessons back into a project template so the next team starts with them. See how the risk register tracks owners and responses, and read the project risk management guide for the wider process.