Lessons Learned Template
A session record built to change the next project — factual timeline first, causes not symptoms, systemic findings separated from specific ones, and three owned actions that edit an artefact rather than exhort people.
Markdown. No sign-up, no email.
The deliverable is not this document. It is a change in how the next project runs. Three owned actions beat thirty recorded findings, and actions that edit a template or a checklist beat actions that ask people to remember something.
Project / phase: _______________ Session date: _______ Facilitator: _______________ Attendees: _______________
Held at: milestone / phase end / after a release / project close
Hold these at milestones, not only at close. By close, the early lessons are months old and the people involved have moved on.
1. Timeline — facts first#
Build this from records, not memory. Discussing causes before agreeing facts produces an argument about the facts, usually settled by whoever speaks most confidently.
| Date | What happened | Source |
|---|---|---|
Planned vs actual: start ____ / ____ · finish ____ / ____ · budget ____ / ____ · scope delivered ____%
2. The five questions#
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? _______________
3. Findings#
Separate these two, because they need different audiences and different actions.
Specific to this project#
| # | Finding | Cause (a condition, not a person) |
|---|---|---|
Systemic — will recur on every project until something changes#
| # | Finding | Cause | Who can actually change this |
|---|---|---|---|
🔴 The systemic findings are the valuable ones and the uncomfortable ones — they usually implicate funding, governance, resourcing or dependencies rather than the delivery team. If your review only ever produces project-specific findings, the wrong people are in the room.
4. What worked#
| # | What | Why it worked | Worth repeating? |
|---|---|---|---|
Reviews that only catalogue failures teach teams to avoid things without teaching them what to do, and they make the session unwelcome.
5. Actions — three is plenty#
Prefer actions that change an artefact. The next team then benefits without knowing a lesson existed, which is the only mechanism that reliably survives.
| # | Action | Type | Owner | Due | Done |
|---|---|---|---|---|---|
| 1 | edit a template/checklist / change a process step / brief someone / escalate | ||||
| 2 | |||||
| 3 |
Findings we are NOT actioning, and why: _______________
Recording that honestly is better than assigning something to a role that will not act on it.
6. Handover to the next project#
- [ ] Templates or checklists edited (which: ____________)
- [ ] Process step added or removed (which: ____________)
- [ ] Outgoing PM briefed the incoming PM directly
- [ ] Previous project's actions reviewed at this project's start — done? yes / no
That last box is what makes the process visibly consequential rather than ceremonial. One agenda item, ten minutes.
7. Recurrence check#
| Finding | Seen before on | How many times |
|---|---|---|
A recurring finding 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 turns "we think this is a problem" into "this has now cost us three times".
Sign-off#
| Name | Date | |
|---|---|---|
| Facilitator | ||
| Project manager | ||
| Sponsor informed | ||
| Actions reviewed on |