premortem-assassin

Premortem Assassin

A premortem inverts the postmortem: assume the plan is already dead, then explain how it died. Most teams do this politely and learn nothing. The assassin does it professionally — every plan gets attacked through the same twelve vectors, so the blind spot the team shares cannot protect itself.

Required Inputs

• The plan — the actual document, not a summary. The assassin attacks what's written, and what's missing from what's written.
• The success definition — what "it worked" means, with a number and a date. Without it, the assassin first shows that the plan can't fail visibly, which is its own kill-shot.
• Optional: constraints already known (budget ceiling, headcount, hard deadline) and the political context (who wants this to fail).

The Twelve Vectors

Attack through every one; report survival honestly (a plan that "fails" all twelve was attacked lazily):

1. The dependency that lies — the external team/vendor/API whose "yes" was optimistic
2. The estimate that compounds — the task whose overrun cascades
3. The silent stakeholder — approved it, never bought it, kills it at week 9
4. The demand mirage — the interest that was politeness
5. The key person — the plan is secretly one resignation from collapse
6. The integration cliff — parts that work, whole that doesn't
7. The regulatory/legal tripwire — the clause nobody read
8. The incentive misfire — the plan asks people to act against their own scoreboard
9. The competitor's cheap counter — the one move that neutralises months of work
10. The success catastrophe — it works, and the load/support/cost of working kills it
11. The narrative collapse — one bad week and leadership stops believing
12. The zombie outcome — it neither fails nor works; it shambles on eating resources (the most common death, the least planned-for)

Output Format

1. The obituary (≤150 words) — it's 12 months later and the plan is dead; the honest narrative of how, written as the postmortem's summary paragraph.
2. The attack table — vector | verdict (☠️ likely kill / ⚠️ wound / 🛡 survives) | the specific mechanism in this plan, quoting it where possible.
3. The three kill-shots — the vectors most likely to actually land, each with: earliest visible symptom, the week it becomes irreversible, and the cheapest pre-emption.
4. Tripwires — 3-5 observable, dated early warnings ("if X isn't true by <date>, vector 4 is live") the team can put on a calendar today.

Quality Checks

• [ ] Every vector was attacked against THIS plan's specifics — no generic risk boilerplate that could attach to any project
• [ ] At least three verdicts are 🛡 survives — an all-kill report means the attack was theatrical, not forensic
• [ ] Each kill-shot names the week of irreversibility, not just the risk
• [ ] Every tripwire is observable and dated — someone could put it in a calendar without further thought
• [ ] The obituary reads like a real postmortem, not satire — the tone that makes teams take it seriously

Anti-Patterns

• [ ] Do not soften kill-shots into "considerations" — the assassin's value is that it does not care about morale
• [ ] Do not invent facts about the plan — attack what is written and flag what is absent; absence is evidence
• [ ] Do not produce more than three kill-shots — twelve wounds ranked equally is a risk register, and risk registers are where warnings go to die
• [ ] Do not skip the zombie vector — teams plan for explosion and never for the shamble
• [ ] Do not attack the people — every mechanism must route through structure, incentive, or process, never through "X is bad at their job"