Glossary

Lessons Learned

Lessons learned are the documented insights a team captures during or after a project — what worked, what didn't, and what should change — so the next piece of work benefits from the last. A core project-management practice, recognised by PMI and PRINCE2, it only pays back when a lesson becomes an actual change.

Lessons learned are the insights a team captures from a project — what went well, what went badly, and what should be done differently next time — recorded so future work benefits from past experience. The term comes from established 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" one of its core principles, maintained in a dedicated lessons log.

Why it matters

Lessons learned matter because the same mistakes are expensive to make twice. A team that captures and applies its lessons stops paying for the same failure on every project; a team that doesn't keeps rediscovering the same potholes. The catch is that documentation alone changes nothing. The value isn't in the log — it's in whether the next piece of work is actually run differently because of it.

The hard part: making a lesson stick

The honest failure mode is a lessons-learned register that grows after every project and is never opened before the next one. A lesson only counts when it becomes something the next team encounters by default — a step added to a checklist, a rule in the process, a question on a hand-off form. When the same lesson keeps reappearing, that repeated pain is system information: a signal the process, not the people, needs changing. Deciding whether a recurring pain is worth a permanent fix is what the Pain Automation Score helps you judge. For the practical method, see how to run a lessons-learned session.

Frequently asked

Is a lessons-learned the same as a retrospective or after-action review?

They overlap heavily. A retrospective (agile) and an after-action review (originally a US Army practice) are both formats for capturing lessons learned; 'lessons learned' is the broader project-management term for the insights themselves and the log they live in. In practice the words are often used interchangeably — the distinction that matters is whether anything actually changes as a result.

When should you capture lessons learned?

Capture them continuously, not just at the end. PRINCE2 keeps a lessons log open for the whole project so insights are recorded while they are still fresh, then reviews them at each stage boundary and at closure. Waiting until the post-project review means the most useful detail has already been forgotten.

What goes in a lessons-learned log?

Each entry names the situation, what happened, the impact, and the specific recommendation or change for next time — ideally with an owner. A log of vague observations ('communication could be better') is just a complaint board; a useful one records changes precise enough to act on.

Why are lessons learned so often ignored?

Because most are written down and never turned into a change. Research on project knowledge has repeatedly found that lessons are captured but rarely reused, partly because they sit in a document nobody reads on the next project. The fix is to convert each lesson into a checklist item, a process change or a rule that the next team can't help but encounter.

Term

After-Action Review (AAR)

An after-action review is a short, structured debrief that asks four questions: what was supposed to happen, what actually happened, why was there a difference, and what will we change? Originally a US Army practice, it turns experience into improvement — and works best when it's blameless but accountable.

Term

Root Cause Analysis (RCA)

Root cause analysis (RCA) is a structured way to find the underlying cause of a problem — not just its symptoms — so a fix stops it coming back. It uses tools like the 5 Whys, fishbone diagrams and Pareto analysis to move from "what happened" to "why", and ends in a change with a named owner and a date.

Guide

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

To run a lessons-learned session, gather the people who did the work, ask four questions — what was meant to happen, what happened, why the difference, and what we'll change — keep it blameless but accountable, then turn each lesson into one specific change with a named owner and a date. Without that last step, it's a document nobody reads.

← Back to the glossary