# Pre-mortem: [Project or plan name]

> A pre-mortem is a short team session held before a plan starts. The team imagines that the
> plan has already failed, writes down every plausible reason why, and turns the strongest
> reasons into mitigations and early warning signs. The method follows Gary Klein, "Performing
> a Project Premortem", *Harvard Business Review*, September 2007, cited as a reference only.
> Replace every `[bracketed]` value and every row marked *Example*. Worked examples use
> Thistlebank Software, a fictional company, moving customer billing to a new platform.

<!--
Guidance: How to use this template
- Run the session after the plan is understood but before it is locked, so that findings can
  still change scope, dates or staffing.
- The leader states the failure as a fact ("it is six months from now and the project failed"),
  not as a question. Stating it as certain gives people permission to name risks they would
  otherwise keep to themselves.
- Everyone writes alone first (section 3). Discussion before silent writing lets the most senior
  or most confident voice set the list.
- Common pitfall: a long list with no owners. Stop at the five to eight causes that matter most
  and give each one a mitigation, a warning sign and an owner.
- Related templates: RAID log (`project/raid-log`), Decision meeting brief
  (`meetings/decision-meeting-brief`), After-action review (`meetings/after-action-review`).
-->

## Session details

<!-- Guidance: Keep one record per session. Invite the people who will do the work and at least one person from outside the team who will depend on the result. -->

| Field | Value |
|---|---|
| Plan under review | [Project, launch, migration or decision] |
| Session date and length | YYYY-MM-DD, [60] minutes |
| Facilitator | [@facilitator] |
| Plan owner | [@owner] |
| Participants | [@name], [@name], [@name] |
| Imagined failure date | [Date or milestone at which we pretend the plan has failed] |
| Record status | [Draft / Actions agreed / Closed] |

## 1. The plan in one paragraph

<!-- Guidance: Restate the goal, the success measure and the key dates in a few lines so that everyone imagines the failure of the same plan. -->

[Goal, success measure, key milestones, team and budget.]

*Example:* Thistlebank Software will move all 3,200 customer accounts from its legacy billing
system to a new subscription billing platform, with the first invoices issued from the new
platform at the start of the next quarter. Success means invoices match the legacy amounts to
the cent and no more than 1% of customers contact support about billing in the first month.

## 2. The failure scenario

<!-- Guidance: Read this out at the start. Make it vivid and certain, and fix a point in time. -->

"It is [date]. The [plan] has failed badly. [Describe the visible outcome: missed date, angry
customers, cost overrun, cancelled launch.] Take [ten] minutes and write down every reason you
can think of for why it failed, especially the ones that would be awkward to say out loud."

## 3. Session agenda

<!-- Guidance: Keep the timings. The silent writing block is the core of the method and should not be cut. -->

| Time (min) | Step | Output |
|---|---|---|
| 5 | Brief the plan (section 1) | Shared picture of the plan |
| 5 | Announce the failure (section 2) | Everyone imagines the same failure |
| 10 | Silent writing, alone | Individual lists of reasons |
| 15 | Round-robin: one reason per person per turn until lists run out | Full list, no debate yet |
| 10 | Group and score the reasons (section 4) | Top causes |
| 10 | Mitigations and warning signs (section 5) | Actions with owners |
| 5 | Close: confirm owners and review date | Agreed record |

Total: 60 minutes.

```mermaid
flowchart LR
  A["Brief the plan"] --> B["Announce the failure"]
  B --> C["Silent writing"]
  C --> D["Round-robin list"]
  D --> E["Group and score"]
  E --> F["Mitigations and warning signs"]
  F --> G["Update plan and RAID log"]
```

## 4. Failure causes, grouped and scored

<!-- Guidance: Merge duplicates, then score likelihood and impact from 1 (low) to 3 (high). Score = likelihood x impact. Keep the original wording of minority views; they are often the most useful. -->

| ID | Cause of failure | Likelihood (1-3) | Impact (1-3) | Score |
|---|---|---|---|---|
| PM-01 *(Example)* | Reconciliation finds invoice mismatches only in the final week, too late to fix | 3 | 3 | 9 |
| PM-02 *(Example)* | Payment provider certification of the new platform takes longer than planned | 2 | 3 | 6 |
| PM-03 *(Example)* | Support team is not trained on new invoice layouts and cannot answer questions | 2 | 2 | 4 |
| PM-04 *(Example)* | The only engineer who knows the legacy pricing rules leaves mid-project | 1 | 3 | 3 |
| [PM-NN] | [cause] | [1-3] | [1-3] | [score] |

## 5. Mitigations and early warning signs

<!-- Guidance: For each top cause, name a change to the plan, a sign you would see early if the cause were happening, and one owner. A mitigation that nobody owns is a wish. -->

| ID | Mitigation (change to the plan) | Early warning sign | Owner | Due |
|---|---|---|---|---|
| PM-01 *(Example)* | Run a full parallel billing cycle two months before go-live and reconcile every account | More than 0.5% of accounts differ in the parallel run | [@billing-lead] | YYYY-MM-DD |
| PM-02 *(Example)* | Book the certification slot now and add four weeks of float | No confirmed slot by the end of this month | [@payments-pm] | YYYY-MM-DD |
| PM-03 *(Example)* | Train support with real sample invoices before the parallel run | Support cannot answer five test questions | [@support-lead] | YYYY-MM-DD |
| PM-04 *(Example)* | Pair a second engineer on pricing rules and write them down | Pricing questions still routed to one person | [@eng-manager] | YYYY-MM-DD |
| [PM-NN] | [mitigation] | [signal] | [@owner] | YYYY-MM-DD |

## 6. Follow-up

<!-- Guidance: Copy the top causes into the project RAID log the same day, and review the warning signs at a fixed checkpoint. -->

- [ ] Top causes added to the RAID log with the same PM IDs.
- [ ] Plan, schedule or budget updated where a mitigation changes them.
- [ ] Warning signs reviewed at [checkpoint or date] by [@owner].
- [ ] Record shared with all participants within one working day.

## Standard and licence note

Based on the premortem method described by Gary Klein, "Performing a Project Premortem",
*Harvard Business Review*, September 2007. Official text: Harvard Business Review, purchase or
licensed access: https://hbr.org/2007/09/performing-a-project-premortem. The method draws on
research into prospective hindsight: Mitchell, Russo and Pennington, "Back to the future:
Temporal perspective in the explanation of events", *Journal of Behavioral Decision Making*
2(1), 1989, pages 25 to 38, https://doi.org/10.1002/bdm.3960020103. No text is copied from
either publication; the agenda, scoring and tables are original. Template licence: MIT.