WHAT GOES WRONG · LESSON 08.07advanced

The autopsy — running a postmortem on a failed project.

Blameless. Specific. Actionable. Read by future teams.

↳ tl;dr

A project autopsy (postmortem) is structured reflection on a failed (or struggling) project. Done well, it's the institutional memory that prevents the same failure from recurring. Done badly, it's a blame ritual that scares future teams into hiding problems.

The four parts

  1. What happened — facts. Timeline. What was planned vs. what actually shipped (or didn't).
  2. Why it happened — root causes. Not surface symptoms. Use 5-Whys or fishbone analysis.
  3. What we learned — generalizable lessons. Not specific to this team or this project.
  4. What changes — concrete process or system changes. With owners and dates.

Blameless

The single most important rule. Postmortems that name individuals teach future teams to hide problems. Postmortems that focus on systems and decisions teach future teams to surface problems. The site reliability engineering literature (Google's SRE book) is unequivocal on this.

the political-cover trap

Blameless doesn't mean "no accountability." If a specific decision was wrong, name the decision and what made it wrong — without naming the decider as a bad person. The decider can be the right person who made a wrong call; the autopsy is about understanding the call, not the person.

Make it readable

Most autopsies die in archived folders. The good ones get read by future teams considering similar work. Write the autopsy as if a stranger will read it in two years and decide something based on it — because that's what should happen.

// sources

Sources cited

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.

// sources

Further reading

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.