# Lessons Learned

> 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 | | |