文件预览

premortem.md

查看 🧠 Thinking Frameworks 技能包中的文件内容。

文件内容

references/premortem.md

# Premortem

**Premortem** is a proactive risk analysis technique where you assume a project or decision has already failed catastrophically, then work backwards to identify what could have caused that failure. Unlike a postmortem (which analyzes failures after they happen), a premortem helps you prevent failures before they occur. Research shows this technique can reduce project failure rates by surfacing risks that teams are reluctant to voice during normal planning.

---

Conduct a **premortem** on the following plan or decision. Follow every step below — be brutally honest and imaginative.

**Plan / Decision:**
$ARGUMENTS

---

## Step 1: Assume Catastrophic Failure

- Imagine it is **6-12 months in the future**.
- The project has failed **spectacularly**. It's not just a minor setback — it's a complete disaster.
- Stakeholders are furious. Resources were wasted. Reputation is damaged.
- **Write the headline** of the failure: *"Project X Collapses: [Specific Catastrophic Outcome]"*

## Step 2: Generate Failure Scenarios

- Brainstorm **at least 10 specific reasons** why this failure occurred.
- For each reason, ask:
  - What specific event or condition caused this?
  - Was this a known risk that was ignored?
  - Was this a surprise (unknown unknown) or a blind spot (known but unacknowledged)?
- Think across categories:
  - **Technical** — Architecture flaws, integration failures, scalability issues
  - **Human** — Team dynamics, skill gaps, burnout, turnover
  - **Market** — Customer rejection, competitive response, timing issues
  - **Operational** — Process breakdowns, communication failures, resource constraints
  - **External** — Regulatory changes, economic shifts, supply chain disruptions

## Step 3: Identify the Most Likely Failure Modes

- Review all failure scenarios and rank them by:
  - **Likelihood** — How probable is this failure mode? (High/Medium/Low)
  - **Impact** — How severe would the consequences be? (Critical/High/Medium/Low)
  - **Detectability** — How early would we notice warning signs? (Early/Mid/Late/Too Late)
- Focus on **high-likelihood + high-impact** scenarios — these are your critical risks.

## Step 4: Surface the Uncomfortable Truths

- Which failure scenarios are people **reluctant to discuss**?
- What concerns have been **dismissed or minimized** during planning?
- Who on the team might have **private doubts** they haven't voiced?
- What assumptions are we making that, if wrong, would be catastrophic?

## Step 5: Design Preventive Measures

For each critical risk (high likelihood + high impact):
- **Prevention:** What can we do NOW to prevent this failure mode entirely?
- **Mitigation:** If prevention fails, how can we reduce the impact?
- **Early Warning:** What leading indicators would alert us that this risk is materializing?
- **Contingency:** What is our backup plan if this risk occurs despite our efforts?

## Step 6: Assign Ownership and Triggers

- For each preventive measure and contingency:
  - **Who owns** monitoring and execution?
  - **What trigger** activates the contingency plan?
  - **When** will we review and update these safeguards?

## Step 7: Decision Point

- Given this premortem analysis:
  - Should we **proceed** with the current plan (with safeguards in place)?
  - Should we **modify** the plan to address critical risks?
  - Should we **delay** until key uncertainties are resolved?
  - Should we **abandon** the plan entirely (failure risk too high)?

---

**Remember:** The goal of a premortem is not to kill good ideas through excessive caution. It's to make good ideas *actually succeed* by surfacing and addressing risks before they become failures. If the premortem reveals fatal flaws, that's a feature, not a bug — it saves you from wasting resources on a doomed effort.