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 |