Lessons Learned: Capturing What Actually Happened, Usefully

Almost every organisation runs lessons learned sessions. Almost none of them change the next project. The findings are recorded, filed in a repository, and the following team repeats the same mistakes — frequently the identical mistakes, described in the same words, because nobody read the document and nobody was going to.

The problem is rarely the session. It is that "capture" is treated as the deliverable, when the only outcome that matters is a change in how the next project is run.

Why the repository does not work#

The standard model: hold a workshop at project close, record findings, upload to a shared location, instruct future projects to consult it.

It fails for reasons that are entirely predictable. Nobody searches a repository for problems they do not yet know they will have. The findings are written in project-specific language that means little out of context. They arrive at the end, when the team has dispersed and the people who could act have moved on. And the volume grows until finding the relevant lesson costs more than learning it again.

Treat the repository as a record, not as a mechanism. The mechanism has to be something that reaches a team without them looking for it.

What makes a finding useful#

A cause, not a symptom. "Testing was rushed" is an observation. "The test window was fixed at plan time and absorbed every upstream delay, because no rule protected it" is a cause, and it suggests a specific change.

Specific enough to act on. "Improve communication" appears in a large share of all lessons learned documents ever written and has never changed anything. "Stakeholders in three departments learned about the interface change from the release notes; there was no route for them to be consulted during design" can be acted on.

Blameless. Not because feelings matter more than accuracy, but because a review that assigns blame produces defensive accounts, and defensive accounts are inaccurate. You lose the information you convened to collect. The root cause of a person's mistake is nearly always a condition — an unclear process, missing information, time pressure, a system that made the wrong action easy.

Owned by someone who can change something. A finding with no owner is an observation. The useful question is not "what did we learn" but "what will be different, who is making it different, and by when".

Including what worked. Reviews that only catalogue failures teach teams to avoid things without teaching them what to do, and they make the session unwelcome.

Running the session#

Hold it while people remember. At the end of a phase, after a significant release, at a milestone — not only at project close, by which time the early lessons are eight months old and the people involved have moved on.

Build a factual timeline first. What happened and when, from records rather than memory. Discussing causes before agreeing facts produces an argument about the facts, usually shaped by whoever speaks most confidently.

Ask the same questions each time. What did we expect and what happened instead? Where did we lose time, and what was the queue? What did we discover late that we could have known earlier? What would we do identically? What surprised us?

Separate the systemic from the specific. Some findings apply only to this project. Others describe how the organisation works and will recur on every project until something changes. Those are the valuable ones, and they are also the uncomfortable ones — they usually implicate funding, governance or resourcing rather than the delivery team.

Produce a small number of owned actions. Three actions with owners and dates beat thirty findings in a document. If nobody will own it, say so honestly in the record rather than assigning it to a role that will not act.

Making findings actually reach the next team#

This is the part that is nearly always missing, and it is the difference between learning and recording.

Change the artefacts. If a lesson concerns something a checklist or template should have prevented, edit the checklist or the template. The next team then benefits without knowing a lesson existed. This is by far the most reliable mechanism available.

Change the process, not the exhortation. "Involve security earlier" achieves nothing; adding a security review to the design gate achieves it structurally.

Brief the next project directly. A twenty-minute conversation between the outgoing and incoming project managers transfers more than a document ever will.

Review the previous project's actions at the new project's start. One agenda item, and it makes the process visibly consequential rather than ceremonial.

Why sessions go wrong#

Held only at close. The last phase dominates, because it is what people remember.

Attended only by the delivery team. The most valuable lessons frequently concern decisions made elsewhere — funding, procurement, governance. Without those people present, the findings stop at the team boundary.

Blame in the room. One pointed comment early and the rest of the session becomes careful.

Findings with no owner. Recorded, filed, never acted on. Within two cycles everyone knows the session is theatre.

No follow-up. Actions from the last review are never revisited, so the current review's actions are correctly understood to be optional.

Success is not examined. Projects that went well are closed with congratulations and no analysis, so nobody learns what to repeat.

A realistic starting point#

At each significant milestone, hold a one-hour session. Build the timeline from records first. Ask the five questions. Separate project-specific findings from systemic ones. Agree three actions with named owners and dates — and prefer actions that edit a template, a checklist or a process step, because those persist without anybody remembering them.

Then, at the start of the next project, spend ten minutes reviewing whether those three things happened.

FAQ#

How is this different from an agile retrospective?#

Scale and horizon. A retrospective examines how a team works over a short cycle and produces small adjustments. Lessons learned examine a project or phase and frequently surface organisational issues a team cannot fix alone. Teams that run good retrospectives still benefit, because the systemic findings are invisible at sprint level.

Who should attend?#

The delivery team, the sponsor or their representative, and anyone whose decisions materially shaped the project — procurement, architecture, operations, the business owner. Restricting it to the delivery team confines the findings to what the delivery team controls.

How do we keep it blameless when a person genuinely made a mistake?#

By asking why the mistake was possible. Someone deployed the wrong build — was the environment labelled clearly, was there a confirmation step, was it 20:00 at the end of a long day? The condition is what will cause it again with a different person. This is not about excusing; it is about fixing the thing that will recur.

Should the findings be published internally?#

Broadly, yes — with judgement about anything commercially or personally sensitive. Lessons kept within one team stay within one team, and the systemic findings are exactly the ones other teams need.

What if the same lesson keeps recurring?#

Then it is not a lesson, it is an unaddressed structural problem, and recording it again will not help. Escalate it as a decision needed with an owner. Recurrence is useful evidence: it converts "we think this is a problem" into "this has cost us three times".

Is a template useful?#

A short one, to keep sessions consistent and comparable. A long one shifts the effort into completing the form. The most valuable fields are the timeline, cause, systemic-or-specific, and the owned action with a date.

How do we measure whether the process works?#

By whether findings recur. If the same causes appear across projects, the capture is working and the acting is not. That is a far better measure than counting lessons recorded.

Related Articles#

Assess against the Project Charter success criteria, review what the Risk Register predicted, and check whether Change Management held the boundary.

What else is coming for Lessons Learned