How to Run a Lessons-Learned Session That Actually Changes Things

A lessons-learned session is worth running whenever a piece of work taught you something a future team would pay to know in advance. The point is not to file a report. It's to leave the room with a small number of changes that mean the next project goes better — and to make sure those changes actually happen.

What is a lessons-learned session?

A lessons-learned session is a structured review where a team examines a finished project or phase to capture what worked, what didn't, and what should change next time. It's a long-standing project-management practice: the Project Management Institute's PMBOK Guide treats capturing lessons as part of closing any project, and PRINCE2 (Axelos) makes "learn from experience" a core principle backed by a dedicated lessons log. The format varies; the intent never does — turn experience into improvement.

The four questions to ask

The simplest reliable structure is the four-question frame borrowed from the US Army's after-action review (AAR). It was formalised by the US Army in the 1970s and has since spread across business, healthcare and software because it needs no special training to run:

1. What was meant to happen? Agree the original plan or intent. You can't measure a gap without a baseline.
2. What actually happened? Get the honest account, with facts and a timeline, before anyone theorises about why.
3. Why was there a difference? This is where the learning lives — the gap between intent and reality, and what produced it.
4. What will we change? Convert the gap into a specific change for next time.

If you only remember one thing, remember that the first three questions are worthless without the fourth. A session that ends at "why" is a good conversation; a session that ends at "what we'll change" is a system that gets better.

Who runs it, and who's in the room

A lessons-learned session needs a facilitator who is close to the work but not defending it. Their job is to keep the four questions moving, protect honesty, and make sure each lesson lands on an owner — they run the process, not the verdict. Invite the people who did the work and saw the problems first-hand, plus at least one person who can authorise the changes you agree. Keep the group small. A packed room with senior observers suppresses candour, and candour is the entire input.

Keep it blameless, but accountable

The most common way a lessons-learned session fails is by turning into a hunt for who to blame. The moment it does, people stop telling the truth and the session learns nothing. The discipline is to keep it blameless but accountable: separate the question of what in the system let this happen from any question of individual fault, and still end with a concrete change that has an owner. Blameless protects the input; accountable protects the output. You need both.

"Bad news early is not a failure. Surprise is." — The Control Standard

Turn each lesson into an actual change

This is the step almost everyone skips, and it's why so many lessons-learned logs are graveyards. A lesson written as an observation — "communication could be better" — changes nothing. A lesson written as a change does:

The test for a real lesson is simple: could the next team encounter it without having read your document? If the answer is no — if it only lives in a register someone has to remember to open — it isn't yet a lesson, it's a note. The durable forms are a checklist item, a step in the process, a rule, or an automation. Each one should have a named owner and a date, and someone should check, weeks later, that it actually landed.

Why most lessons learned are never used

The honest reason lessons learned underperform is that capturing them and using them are two different jobs, and organisations are far better at the first. Research on project knowledge management has repeatedly found that lessons are documented but rarely reused — they're recorded at closure, filed, and never retrieved on the next project, so the same mistakes recur.¹ Writing about the wider problem of organisational learning, Harvard Business Review has noted that most companies are "remarkably bad" at learning from experience precisely because review rarely translates into changed behaviour.² The fix isn't a better template. It's wiring each lesson into the work itself.

When the same lesson keeps coming back

A single session improves one project. The bigger prize is the pattern: when the same lesson keeps reappearing across projects, that repeated pain is system information — a signal the process, not the people, needs changing, and a recurring cost that is the drift tax in action. At that point the question shifts from "what will we change this time?" to "is this worth a permanent fix — a standing checklist, a rule, an automation, or purpose-built software?" Deciding that is exactly what the free Pain Automation Score below helps you judge in about five minutes.

1. See, for example, Williams, T. (2008), "How Do Organizations Learn Lessons From Projects — and Do They?", IEEE Transactions on Engineering Management — a review finding lessons are widely captured but seldom reused. ↩

2. Gino, F. & Staats, B. (2015), Why Organizations Don't Learn, Harvard Business Review. ↩