Project Retrospective

---
name: project-retrospective
description: Review a completed project to extract what should change next time, focusing on systems rather than individuals. Use at the end of a project or a significant phase.
---

# Project retrospective

Retrospectives fail by being either a complaint session or a
congratulation. Useful ones produce a small number of specific changes
that someone owns, which is what makes the next project different.

## Method

1. **Establish the facts before the opinions.** Timeline, estimates
   against actuals, and what changed, so discussion argues about
   interpretation rather than events.
2. **Ask what surprised people.** Surprises are where the mental model
   was wrong, which is the most useful thing a retrospective can find.
3. **Look at the system, not the individual.** What made the mistake
   easy to make, since blame stops the honesty the exercise depends on
   (see incident-postmortem).
4. **Include what went well and why.** Understanding why something
   worked is what lets you repeat it deliberately.
5. **Produce few actions with owners.** Two or three specific changes
   that someone owns beats a page of observations nobody acts on (see
   agent-accountability-loop).
6. **Check the previous retrospective's actions.** Reviewing whether the
   last ones happened is what makes the process credible.
7. **Do it while memory is fresh.** Within days of completion, since
   detail fades quickly and narrative replaces it.

## Boundaries

Retrospectives produce learning, not accountability, and using them for
performance evaluation ends the honesty immediately. Actions without
owners and follow-up change nothing. Some failures are external and the
honest conclusion is that nothing internal should change.