Project Closure and Lessons Learned: Really Learning From Projects

Why lessons learned so often have no consequences

The project has been accepted, the invoice sent, the team relieved. Half an hour at the end of a long day is left for the review. People collect what went well and what did not, someone types it into a document, and the document ends up in the project folder. Six months later a similar project begins. Nobody opens the folder, and the discussion with the customer about the scope of work is again held too late.

The problem is rarely that teams notice nothing. They know very well what went wrong. What is missing is the path from insight to change. This article therefore answers the question: how does closing a project turn into actual learning instead of a report? To answer it, we first clarify what project closure and a lesson are, introduce a thinking model on the depth of learning, examine the research, and then describe a 60-minute closure review and how to phrase lessons that work.

A lesson that changes nothing is not learning but minutes of a meeting.

What belongs to project closure, and what is a lesson?

Project closure is the last phase of a project. It includes acceptance by the client, the post-calculation, meaning the comparison of planned and actual costs and times, the handover of open items to ongoing operations, and the review. The review is cut short most often, because the next project is already waiting.

A lesson learned, according to the definition Dagenais and colleagues (2025) derive from the literature, is a statement or recommendation drawn from positive or negative experiences and intended to guide future action. It does not arise from a spontaneous memory but from a systematic review, and it is phrased so that others can apply it in a similar situation.

The thinking model: single-loop and double-loop learning

The organizational researchers Chris Argyris and Donald Schön (1978) distinguished two kinds of learning. In single-loop learning, a mistake is corrected without examining the underlying assumption. In double-loop learning, the assumption, the goal, or the rule itself is also questioned. Argyris used the image of a thermostat: a thermostat that turns on the heat at 18 degrees learns in a single loop. A thermostat that could ask whether 18 degrees is the right temperature would learn in a double loop.

Both forms have their place. Not every mishap calls for questioning goals. But anyone who only learns in a single loop after every project keeps correcting the same symptoms.

What research shows about debriefs and lessons learned

That structured debriefs work is well documented. The article on learning from bad decisions describes the meta-analysis by Tannenbaum and Cerasoli (2013): across 46 samples with a total of 2,136 participants, debriefs improved performance by about 25 percent on average. A fixed procedure and a clear purpose strengthened the effect.

Dagenais and colleagues (2025) examined how good lessons are produced in a rapid literature review. Of 1,881 documents found, 18 remained that describe how lessons are derived, published between 2000 and 2020. From these, the authors derive three principles: a climate in which successes and failures can be discussed openly, credible leadership of the process, and a systematic approach. This includes collecting lessons not only at the end but also during the project, because memory otherwise smooths things over. Lessons should be checked by those involved before they count, and in the end feed into training and project planning.

What the authors identify as a gap in the literature is remarkable. Only a few sources describe how collected observations become a lesson, and the actual application of lessons is hardly studied systematically. In addition, those who lead the review can unconsciously steer the results toward their own expectations. For a company this means: whoever moderates the review should not be the person who shaped the project most, or should at least speak last.

A case study by Bredell and Tshuma (2025) in a project-based organization in South Africa offers a practical pointer. Based on interviews, a focus group, and a review of the existing collection of lessons, they concluded that lessons are passed on better when they are phrased as risks for future projects. A risk finds a place in the planning of the next project. An insight in a closing report usually does not. It is a single organization, but the idea transfers easily.

Two views: collect or build in?

The first view relies on collection. Lessons are gathered in a database or a shared document, sorted by keyword, and reviewed before every new project. In favor of this is that knowledge does not depend on individuals. Dagenais and colleagues explicitly recommend archiving lessons in an accessible way.

The second view relies on building in. A lesson is not collected but immediately transferred into the tool that will be used next time anyway: the project start checklist, the quote template, the list of risks. In favor of this is the finding that the application of collected lessons is hardly documented in the literature, and the experience that hardly anyone searches a database before a new project.

I consider building in the more effective path and collection the necessary complement. Every lesson gets a destination where it changes something. The collection then serves as a learning register, as described in the article on bad decisions: it records which lesson went where and whether the change worked.

How to review a project in 60 minutes

The review builds on the learning review that Owners Council describes for bad decisions and adds the comparison of plan and actual that belongs to every project. It takes 60 minutes, takes place no later than two weeks after acceptance, and involves three to six people, ideally from all areas that worked on the project.

1. Compare plan and actual (10 minutes)

   Put the numbers side by side: planned and actual hours, costs, deadlines, and scope. The article on project controlling for small businesses describes how to collect these numbers during the project.

2. What did we expect? (10 minutes)

   Everyone writes down for themselves what they expected at the start before anyone speaks. That way memory is not shaped by the first comment.

3. What actually happened? (15 minutes)

   Reconstruct the most important turning points in chronological order, facts only. What went better than expected, what worse?

4. Where does the difference come from? (15 minutes)

   For each deviation, ask about the cause and then one level deeper: which assumption was behind it? This is where it is decided whether learning is single-loop or double-loop.

5. What do we change, and where? (10 minutes)

   At most three lessons, each with a destination, a responsible person, and a review date.

How to phrase lessons that work in the next project

Most lessons fail because of how they are phrased. “Communication with the customer must improve” is true and has no consequences. An effective lesson takes one of two forms: a rule with an if and a then, or a risk for future projects, as Bredell and Tshuma suggest. In both cases it is clear when it applies and what to do then.

The last row points to a common pattern. Many project mishaps are not due to the project itself but to too many projects at once. The article on capacity planning describes how to determine the time actually available. Anyone who keeps a learning register for a year sees where their lessons go.

Where a checklist is the right destination, the article on checklists in the company helps keep it short and usable.

Conclusion: how does project closure turn into actual learning?

The guiding question was how closing a project turns into learning instead of a report. The answer lies less in the meeting than in what happens afterward. Structured debriefs work, that is well documented. They remain without consequences when their results end up as general insights in a document. They become effective when every lesson is phrased as a rule or risk, has a destination where it changes the next project, and has a review date. Whether learning is single-loop or double-loop is decided by the question about the assumption behind the mistake. A company that asks this question regularly makes new mistakes in the next project instead of the old ones, and that is the real progress.

What you can do this week

1. Choose the most recently completed project and invite three to five people involved to a 60-minute review.
2. Prepare the comparison of plan and actual: hours, costs, deadlines, scope.
3. Go through the questions in order and, for each deviation, ask about the assumption behind it.
4. Phrase at most three lessons as a rule or risk, each with a destination, an owner, and a review date.
5. Enter the lessons in the learning register and change the destinations within the same week.

In the next similar project you will notice whether it worked. If the project start checklist prevents the mistake that cost two weeks in the last project, the hour was well invested.