Pre-mortem Template
Pre-mortem session: plan summary, failure scenario, 60-minute agenda, scored failure causes, mitigations with early warning signs and owners
Cara menggunakan: Use it before a plan is locked, to surface risks people hesitate to raise. Fill the plan summary and failure scenario first, then run silent writing before any discussion. The main pitfall is a long list of causes with no mitigations or owners.
Pratinjau
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.
Session details
| 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
[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
"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
| 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.
4. Failure causes, grouped and scored
| 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
| 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
- 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.
Templat terkait
After-Action Review Template (AAR)
After-action review: objectives and intent, timeline, planned vs actual, causes, sustain and improve, SMART improvement plan, follow-up (TC 7-0.1, HSEEP AAR/IP)
RapatAGM Agenda and Minutes Template (Notice, Proxies, Resolutions)
Annual general meeting: rules table, timetable, notice, agenda, ordinary and special resolutions, proxy register, quorum, minutes with vote counts, filings
RapatBrainstorming Session Template
Brainstorm: focused question, Osborn rules, silent writing and nominal group variants, remote variant, cluster, dot voting, decisions, follow-ups