Close a Project and Keep the Lessons

62% of project teams have a lessons-learned procedure, but only 12% follow it closely. Project closure turns lessons into owned changes.

Alexander Kiel

Business Analyst · Banking & Wealth Management

03.10.2026 · 8 MIN READ · PROJECT SUPPORT

ON THIS PAGE

1. Confirm the Closure Criteria

2. Hand Over Open Items With Owners

3. Release the Team and Close Access

4. Write the Project Closure Report

5. Run a Blameless Lessons Review

6. Turn Lessons Into Owned Changes

Sample case: NASA

In short

FAQ

Project closure is the last phase of a project. The work is accepted, open items are handed over, the team is released and the lessons are recorded. Most organisations have a process for the last step but do not follow it. In a survey of 522 project professionals, 62.4% said that their organisation had formal procedures for lessons learned. Yet only 11.7% said that such procedures were closely adhered to.

Banks now have a legal duty to learn. Under the EU's Digital Operational Resilience Act, financial entities shall put in place post ICT-related incident reviews after a major ICT-related incident. On request, they must show supervisors the changes that were implemented following post ICT-related incident reviews.

A project that ends with a farewell lunch and an unread report leaves its lessons to chance. Would your next programme know what went wrong in the last one?

Illustrative lessons learned register with one row per lesson and columns for lesson, cause, change required, owner, due date and status, where the change to the cut-over checklist is highlighted as the lesson turned into a real change

0 of 18 done

Click a bullet point to tick it off.

1 · Confirm the Closure Criteria

Could your team say today which criteria must be met before the project counts as closed?

☐

Write the closure criteria into the project plan

☐

Check each criterion against proof before closing

☐

Ask the sponsor to sign the closure off in writing

Keep in mind: A project closed only on the calendar leaves work unfinished. Close on criteria, not on the day the budget ends.

FULL STEP

Agree at the start what "closed" means. For example: scope delivered and accepted, open defects handed over, a benefits owner named and the budget reconciled. At the end, check each point with proof and ask the sponsor to sign the closure off. Without written criteria, projects either drag on for months or stop without a formal end.

The UK project delivery standard states that a programme or project shall be closed in a controlled way. The manager, with the team and key stakeholders, shall undertake a closure review. It adds that stakeholders shall be informed about closure.

2 · Hand Over Open Items With Owners

Who in your bank owns the open risks of the last project your team closed?

☐

List every open risk, issue and action at closure

☐

Name an owner in the business for each open item

☐

Get written acceptance from every new owner

Keep in mind: Open items without an owner who accepts them simply disappear. Ask each owner to confirm the handover, not only to receive it.

FULL STEP

No project closes with every risk, issue and action solved. List what is still open. Hand each item to a named owner in the business, with a date. The owner must accept the item, not just receive an email about it.

The standard expects that responsibilities for ongoing risks, issues, actions and benefit tracking should be handed over to the business, which must accept them. It adds that information and data should be handed over for on-going operational management. For processes the team ran itself, my article on desktop procedures that survive a handover shows how to document them.

3 · Release the Team and Close Access

How many accounts from your last finished project still have access to production data?

☐

Remove project user access and test accounts within five days

☐

Close cost codes, purchase orders and supplier contracts

☐

Archive project files in one agreed place

Keep in mind: Leftover access is an audit finding waiting to happen. Make access removal a closure criterion, not a clean-up task.

FULL STEP

Closing a bank project also means closing what the project opened: user access, test environments, temporary licences, supplier contracts and cost codes. Remove project access within days of closure. Archive the project files. Release the team on a fixed date.

The project delivery standard expects that the team should be reassigned and any temporary facilities demobilised. Access matters even more in a bank. DORA requires policies that limit the physical or logical access to information assets and ICT assets to legitimate and approved functions only. That rules out leftover project accounts.

4 · Write the Project Closure Report

Does your closure report show the gap between the approved baseline and the final result?

☐

Compare scope, dates and cost with the approved plan

☐

List open items with their owners and due dates

☐

Set a date for the first benefits review

Keep in mind: A closure report that only lists successes teaches nothing. Report the gaps and their causes as plainly as the achievements.

FULL STEP

The closure report compares what was planned with what was delivered: scope, dates, cost and quality against the approved plan. It lists what is still open, who owns it and when the benefits will be measured. Keep it short enough for the steering committee to read in one sitting.

Benefits rarely appear on the closure date. The standard asks the sponsoring body to review the extent to which benefits realisation and outcomes meet the business case. It also states that actual benefits realisation should be tracked against the plan. The figures are only as good as the reporting behind them, as my article on RAG status reports explains.

5 · Run a Blameless Lessons Review

Does your team speak openly in lessons reviews, or only about what went well?

☐

Schedule the review before the team is released

☐

Bring facts from the plan, RAID log and decisions

☐

Invite the business and suppliers, not only the project team

Keep in mind: A review that names culprits gets silence the next time. Discuss causes and conditions, not people.

FULL STEP

Hold the lessons review within two weeks of go-live, while memories are fresh and the team is still together. Use facts from the plan, the RAID log and the decision log. Ask what helped, what hurt and what the next project should do differently. Do not look for someone to blame.

Google's site reliability engineers set the standard for this. A review is truly blameless only when it is written to focus on identifying the contributing causes of the incident without indicting any individual or team. DORA asks the same of banks: reviews after an incident shall determine whether the established procedures were followed and the actions taken were effective.

6 · Turn Lessons Into Owned Changes

Which lesson from your last project has changed how your bank runs the next one?

☐

Write each lesson as a change to a template, standard or checklist

☐

Give every change an owner and a due date

☐

Review the lessons register when each new project starts

Keep in mind: A register full of lessons nobody applies is a list of repeated mistakes. Track the changes, not the number of lessons.

FULL STEP

A lesson is learned only when something changes: a template, a checklist, a standard or a training. Record each lesson in a lessons register with the change it needs, an owner and a due date. Review the register at the start of every new project.

The project delivery standard says teams should identify and apply relevant lessons from previous experience when planning the work. The UK National Audit Office explains why: across its reviews of major programmes, we repeatedly see similar problems. Record the agreed changes in the decision log, so the next team can see why the process changed.

Why You Should Have Your Own Black Box | Matthew Syed (Author of Black Box Thinking)

SAMPLE CASE

NASA

In 2001, the US Government Accountability Office asked NASA's programme and project managers about the agency's lessons learned system. In the previous two years, 43 percent of program and project managers have not submitted a lesson. In addition, 58 percent of managers stated that current processes and systems do not allow them to retrieve the right lessons.

On 1 February 2003, the Space Shuttle Columbia broke apart on its return to Earth. All seven astronauts aboard were killed. The investigation board traced the accident to causes rooted in the Space Shuttle Program’s history and culture.

Its report found that the causes of the institutional failure responsible for Challenger have not been fixed, 17 years after the first shuttle loss. Lessons had been written down after Challenger. They had not changed how the programme worked.

Key takeaway: Lessons that stay in a report do not protect the next project. Give every lesson an owner, a change to a standard or a process and a date. Then check that the change happened.

"You really are setting yourself up for a repeat, if you have other organizational or systemic problems."

Harold Gehman (Chairman @ Columbia Accident Investigation Board)

In Short

Project closure works when it follows the same discipline as the rest of the project. Confirm the closure criteria. Hand open items to owners who accept them. Close access and budgets. Write an honest closure report. Review lessons without blame. Turn each lesson into a change with an owner.

The result is a bank that ends projects cleanly and keeps its risks owned after the team leaves. Each new programme then starts with the lessons of the last one.

Frequently Asked Questions

What is project closure?

Project closure is the final phase of a project. It confirms that the agreed scope is delivered and accepted. It hands open risks, issues and actions to named owners, releases the team and closes budgets and access. Lessons learned are recorded as well. It ends with a closure report and the sponsor’s formal sign-off, so the business knows the project is finished.

What should a project closure report include?

A closure report compares the plan with the result: scope, dates, cost and quality against the approved plan. It lists open items with their new owners and says when and how benefits will be measured. It also sums up the main lessons learned. It should be short enough for the steering committee to read and approve in a single meeting.

What is a lessons learned register?

A lessons learned register is a list of lessons from past and current projects. Each entry records what happened, why it matters, the change it needs, an owner and a due date. Project teams review it when a new project starts, so earlier mistakes are not repeated. Without owners and changes, a register becomes an archive nobody reads.