Lessons learned template
A lessons learned review looks back at a finished project, or one stage of it, to find out what went well, what didn't, why, and what you'll do differently next time. This free Word template takes the review from the facts (targets against results, and what happened when) through to lessons with an action, an owner and a date, so the review changes how you work.
Running a company of 30 to 200 people? Documents like this are now worth money.
It suits anything with a start and an end: a system rollout, a product launch, a busy season or a bid you lost. Hold it within a few weeks of the finish, before memories fade and the team scatters.
What's in the template
Lessons learned review
| Project or event | |
|---|---|
| Period covered | |
| Review date | |
| Facilitator | Ideally someone who didn't run the project |
| Attendees | |
| Sponsor | |
| Lessons filed in | e.g. the lessons register on the shared drive |
1. Targets and results
| Objective | Target | Actual | Met? |
|---|---|---|---|
| Finish date | |||
| Budget | |||
| Scope or quality | |||
2. Timeline
The main events and turning points, in order. Agree these before discussing causes.
| Date | What happened |
|---|---|
3. What went well
| What went well | Why it worked | How we repeat it |
|---|---|---|
4. What didn't go well
| What went wrong or took longer | Impact | Root cause |
|---|---|---|
For each root cause, keep asking why until you reach something the company can change.
5. Lessons and actions
| Lesson | Action | Owner | Due | Built into |
|---|---|---|---|---|
Built into: the procedure, checklist, template or training that will change, so the lesson outlives this review.
6. Closing the loop
- Actions added to the team's action plan
- Changed documents updated and reissued
- Lessons filed with tags: type of work, department, customer
- Lessons on the agenda at the next similar project's kick-off
- Follow-up review booked for three months' time
How to run a lessons learned review
- Book it before the project ends and invite the people who did the work, not only those who managed it. Allow 60 to 90 minutes.
- Ask for input in advance: each person's top three things that went well and three that didn't. Quieter people get heard, and the meeting starts with material instead of a blank page.
- Agree the facts before the reasons. Fill in the targets, results and timeline first. Disagreements about what happened are easier to settle than disagreements about why.
- Ask why until you reach something you can change. "The supplier delivered late" is an event. "We signed without checking they had capacity in December" is a cause you can act on.
- Give successes the same attention. Something that went well also has causes, and repeating it is the cheapest improvement available.
- Turn each lesson into an action with one owner and a due date. A lesson with no action is just an observation.
- Say where each lesson will live: a changed procedure, a new checklist line, a step in the project template. Then check the actions at a short follow-up three months later.
How to stop lessons being forgotten
Most lessons logs fail the same way: they're written carefully and never opened again. The UK government's project delivery guidance warns about exactly this, pointing out that putting a lesson in a register doesn't mean anyone will read it. What helps:
- Change the document, not just the log. If the lesson is "check supplier capacity before signing", add that step to the purchasing SOP. The next buyer follows it without needing to know the history.
- Start every project by reading the last one's lessons. Make it a standing item at kick-off meetings.
- Tag lessons by type of work, department and customer, so they can be found next year.
- Track the actions in your action plan like any other work, until they're closed.
- Review as you go. On longer projects, hold a short review at the end of each stage. The same government guidance says learning should happen throughout a project, not only at the end.
- Keep it blame-free. People only report what went wrong when it's safe to. Write lessons about decisions and processes, not individuals.
Example: a fictional retailer's first peak season
Extracts from the review held by a fictional 40-person online homeware retailer after its first Christmas peak on a new warehouse system.
| What happened | Why | Action | Owner |
|---|---|---|---|
| Went well: complaints answered the same day all through December | A 15-minute daily huddle between the warehouse and customer service | Add the daily huddle to the peak-season checklist | Operations manager |
| 300 orders missed the courier collection on the first Monday of peak | Order release settings were left at the supplier's defaults and never tested at peak volumes | Add a full-volume test to the go-live checklist for any system change | IT lead |
| Most picking errors in week one came from temporary staff | They started the day peak began, with half a day's training | Start temporary staff two weeks before peak, each with a named buddy | Warehouse manager |
| Three best-selling lines out of stock by early December | Reorder points were set from average monthly sales, not last year's peak | Set peak reorder points from last year's November and December sales | Buyer |
Common mistakes
- Holding it months later, when the team has moved on and memories have been rewritten.
- Only managers in the room, so the review hears the plan, not what happened on the ground.
- A list of complaints with no causes and no actions.
- Lessons too vague to act on, such as "communicate better". "Copy the warehouse team into the weekly status report" is a lesson.
- Looking for someone to blame. You'll get silence at the next review.
- Filing the report and never reading it again.
Frequently asked questions
What's the difference between a lessons learned review and a retrospective?
They're the same idea at different intervals. Agile teams hold a retrospective at the end of every sprint or iteration to improve how they work while the work continues; a lessons learned review usually comes at the end of a project or stage and looks at the whole thing.
Who should facilitate it?
Someone who wasn't responsible for the project, so the project manager can take part instead of defending decisions. In a smaller company, a manager from another team works well.
What is a lessons register?
A running list of lessons across all your projects. The UK government's project guidance suggests recording, for each lesson, whether it was something that went well or needed improving, who raised it and when, the context, the action and who is accountable, and a status. It also says to keep closed lessons on the register rather than deleting them.