Project Closure That Keeps the Lessons Learned

Close a Project and Keep the Lessons

How banks close a project properly: confirm the closure criteria, hand over open items, close access and budgets, write the closure report and turn lessons into real changes.

Alexander Kiel

Business Analyst · Banking & Wealth Management

03.10.2026 · 8 MIN READ · PMO 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 face 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

STEP 1

Confirm the Closure Criteria

Agree at the start what closed means: scope delivered and accepted, open defects handed over, benefits owner named and budget reconciled. At the end, check each criterion with evidence 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.

✓

Write the closure criteria into the project plan

✓

Check each criterion against evidence before closing

✓

Ask the sponsor to sign the closure off in writing

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

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

STEP 2

Hand Over Open Items With Owners

No project closes with every risk, issue and action resolved. List what is still open and hand each item to a named owner in the line organisation, 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.

✓

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

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

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

STEP 3

Release the Team and Close Access

Closing a bank project also means closing what the project opened: user access, test environments, interim licences, supplier contracts and cost codes. Remove project access within days of closure, archive the project files and 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 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, which rules out leftover project accounts.

✓

Remove project user access and test accounts within five days

✓

Close cost codes, purchase orders and supplier contracts

✓

Archive project files in one agreed location

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

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

STEP 4

Write the Project Closure Report

The project closure report compares what was planned with what was delivered: scope, dates, cost and quality against the approved baseline. 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.

✓

Compare scope, dates and cost with the approved baseline

✓

List open items with their owners and due dates

✓

Set a date for the first benefits review

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

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

STEP 5

Run a Blameless Lessons Review

Hold the lessons learned 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, without looking for someone to blame.

Google's site reliability engineers set the standard for this. A postmortem 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: post-incident reviews shall determine whether the established procedures were followed and the actions taken were effective.

✓

Schedule the review before the team is released

✓

Bring evidence from the plan, RAID log and decisions

✓

Invite the business and suppliers, not only the project team

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

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

STEP 6

Turn Lessons Into Owned Changes

A lesson is learned only when something changes: a template, a checklist, a standard or a training. Record each lesson in a lessons learned register with the change it requires, 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.

✓

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

✓

Give every change an owner and a due date

✓

Review the lessons learned register when each new project starts

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

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

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 surveyed 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 and turn each lesson into an owned change.

The result is a bank that ends projects cleanly, keeps its risks owned after the team leaves and starts each new programme 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, 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 project closure report compares the plan with the result: scope, dates, cost and quality against the approved baseline. It lists open items with their new owners, states when and how benefits will be measured and summarises 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 requires, 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.