Lessons Learned Template and How to Run the Review
A lessons learned review is a short retrospective at the end of a project, where the team records what went well, what to change and who will act on it. Done well, it makes the next project better. Done badly, it produces a document nobody reads. This page gives a template, the questions to ask and examples of lessons that are specific enough to use.
When and how long
Hold it within two weeks of the close, while memory is fresh. Keep it to sixty minutes, with a neutral facilitator if you can. Focus on process and system, not on blame. Aim for three to five lessons that someone will actually apply.
The four-column template
| Area | What went well | What to change | Action and owner |
|---|---|---|---|
| Scoping | The out-of-scope list prevented drift | Confirm data access before sign-off | Add a data checklist to the scope template (Project lead) |
| Interviews | The closing question surfaced a root cause | Schedule earlier | Book interviews in week one (Team lead) |
| Governance | The weekly status kept the sponsor informed | Pre-wire sensitive findings earlier | Add pre-wiring to the plan (Project lead) |
| Handover | The folder was complete | Add notes on each data file | Create a template for data notes (Analyst) |
Add or remove rows to fit your project. The columns that matter most are the last two: a change and an owner.
A fuller structure
For a longer project, extend the one-page template with:
- Review details: project, date, facilitator, attendees.
- Project summary: one paragraph on the aim and what happened.
- Goals versus results: the objectives from the project charter alongside the outcomes.
- What went well.
- What did not go well.
- Timeline of key events: a short list of dates and turning points.
- Lessons and actions: each with an owner and a date.
- Team feedback: anonymous input collected before the session.
- Handover and archive: where the documents are, who has access.
Questions to ask
Start with facts, then move to causes, then to changes.
Facts
- What did we set out to do, and what happened?
- Where did the plan and reality differ most?
Causes
- What helped us most? Why did it work?
- What slowed us down? Why did it happen? (If the answer is a person, ask why the system allowed it. The 5 whys technique helps here.)
Changes
- What are two things we should do again?
- What are two things we should change?
- What would we tell the next team on day one?
Examples of lessons
Weak lessons are vague and impossible to act on. Strong ones are specific.
| Weak | Strong |
|---|---|
| Communicate more | Send the pre-read two days ahead, not the night before |
| Better planning | List data access as a precondition in the scope statement |
| Manage risk | Review the risk log in every weekly status, with an owner for each item |
| Be careful with scope | Name at least two out-of-scope items in every kickoff |
A good lesson has four parts: situation, cause, change, owner.
How to run the session
- Set the rules (5 minutes). The goal is learning, not blame.
- Silent writing (5 minutes). Everyone writes what went well and what did not on separate notes.
- Group and discuss (20 minutes). Cluster the notes, then discuss the biggest clusters.
- Find causes (10 minutes). For the top two issues, ask why until you reach a process cause.
- Choose actions (15 minutes). Turn each into a change with an owner and a date.
- Close (5 minutes). Read back the actions and agree where they will be stored.
The retrospective loop
A lesson is only learned when it changes something. After the session:
- Put the actions in the place the next team will actually look, such as the templates for scope, interviews or governance.
- Update checklists and standard documents.
- Review the actions at 30 and 90 days.
- Close the loop with the sponsor and, where appropriate, with participants. Thank people who gave time, and tell them what was decided and why.
A short worked example
A fictional six-week review for a furniture retailer ends with a retrospective. The team writes four notes about scoping, interviews, governance and handover, then groups them. Two stand out: two interviewees were hard to book late in the project, and the data extract arrived incomplete. Asking why for each, the team finds that interviews were scheduled only after the plan was approved, and that nobody had confirmed data access before the scope was signed. The lessons are then written as changes, not complaints: book interviews in week one, and add a data-access checklist to the scope template. Each has an owner and a date, and both are stored in the template folder that the next team opens first.
Common mistakes
- Waiting too long. Details fade within weeks.
- Blame. A session that names people stops being honest.
- Too many lessons. Ten lessons mean none get applied.
- No owners. Unowned actions do not happen.
- Filing the document. A lesson stored where nobody looks might as well not exist.
- Only covering failures. Record what to repeat, too.
How it fits in a project
A lessons-learned review closes the cycle that begins with a statement of work or charter, runs through regular steering committee updates and ends with the decision and handover. Each stage produces material for the next retrospective.
Go deeper
Guide 12 of The Consultant's Playbook covers the decision memo, the final presentation, the handover checklist, closing the loop with participants and a retrospective with the four-column table above. It includes a complete fictional case that shows a decision being recorded in the room, and a self-check quiz and glossary to test your understanding.
Educational content. It is not legal, financial or tax advice.