Pre-mortem analysis is a project planning technique developed by psychologist Gary Klein where teams imagine a scenario where a project has already failed, then work backward to identify the factors that could lead to that failure. This proactive approach helps teams anticipate and mitigate risks before they occur.
Unlike a post-mortem (which analyzes failure after it happens), a pre-mortem assumes failure will happen and asks "Why?" This mental time travel helps overcome optimism bias and surfaces risks teams might otherwise overlook.
Research suggests that mentally transporting to the future increased the ability to accurately forecast risks by 30%.
- Overcomes planning fallacy (tendency to underestimate time and resources)
- Reduces groupthink by legitimizing concerns
- Surfaces blind spots in planning
- Validates dissenting opinions safely
Ideally conduct 1-3 months before project launch, allowing sufficient time to address identified issues.
Facilitator explains: "It's [date 6-12 months from now]. Our project has failed spectacularly. It's a complete disaster."
Each team member independently writes down reasons for the failure:
- What went wrong?
- What warning signs did we miss?
- What assumptions proved false?
- What external factors derailed us?
Round-robin sharing:
- Each person shares one failure reason
- No judgment or debate yet
- Capture all ideas visibly
- Continue until all reasons exhausted
Group similar failure reasons:
- Technical risks
- Resource constraints
- Communication breakdowns
- External dependencies
- Assumption violations
- Scope creep
Rank risks by:
- Likelihood: How probable is this?
- Impact: How devastating would this be?
- Focus on high-likelihood, high-impact risks
For top risks, create action plans:
- What can we do now to prevent this?
- How will we monitor for early warning signs?
- What's our contingency if it happens anyway?
- Who owns this risk?
- Record all findings
- Assign mitigation owners
- Schedule follow-up pre-mortems if needed
- Why did we miss our deadline by 6 months?
- What caused us to go 200% over budget?
- Why did the client reject our deliverable?
- What made half the team quit mid-project?
- Why did our technology choice prove disastrous?
Team & Resources:
- What key person left the project?
- How did skill gaps derail progress?
- What caused team burnout?
Communication:
- What critical information was never shared?
- How did stakeholder misalignment doom us?
- What assumption was never validated?
Technical:
- What integration proved impossible?
- Why did our technology not scale?
- What security issue destroyed user trust?
External:
- What market change made this irrelevant?
- How did competitor move make this obsolete?
- What regulatory change blocked launch?
- Identify risks before they materialize
- Create mitigation plans with time to implement
- Reduce likelihood and impact of failures
- Legitimizes expressing concerns
- Reduces pressure to appear optimistic
- Surfaces hidden reservations
- Builds psychological safety
- More realistic timelines
- Appropriate resource allocation
- Contingency planning
- Risk-aware decision making
- Teams can proactively address issues
- Enhanced project success probability
- Better prepared for challenges
- Reduced surprise factor
Adapt for individual planning: "It's one year from now. I completely failed at [goal]. Why?"
Opposite approach - imagine wild success: "It's one year from now. We exceeded every goal. How?"
Run both for balanced perspective:
- Identify failure risks
- Identify success factors
- Plan to avoid former, amplify latter
Skipping It: "We don't have time" - but finding time now prevents disasters later
Superficial Analysis: Stopping at obvious risks, missing subtle ones
No Follow-Through: Identifying risks but not creating mitigation plans
Defensive Posture: Team members getting defensive about potential failures
Ignoring Outliers: Dismissing "unlikely" scenarios that could be catastrophic
One and Done: Not revisiting as project evolves
- Before kickoff (initial planning)
- After scope changes
- Before major milestones
- When team composition changes
- After external environment shifts
Especially valuable for:
- High-stakes initiatives
- Innovative/unprecedented work
- Complex technical projects
- Cross-functional efforts
- Projects with many dependencies
- Pre-mortem before sprint/release
- Retrospective (post-mortem) after
- Continuous risk identification
- Pre-mortem feeds risk identification
- Document risks in register
- Track mitigation progress
- Inform timeline estimation
- Guide resource allocation
- Shape contingency planning
Pre-Mortem:
- Timing: Before project starts
- Purpose: Prevention
- Mindset: Proactive
- Focus: What could go wrong
- Outcome: Mitigation plans
Post-Mortem:
- Timing: After project ends
- Purpose: Learning
- Mindset: Reflective
- Focus: What did go wrong
- Outcome: Lessons learned
Digital:
- Mural pre-mortem template
- Miro collaboration boards
- Google Docs/Sheets
- Project management tools
In-Person:
- Sticky notes on wall
- Whiteboard brainstorming
- Index cards for voting
- Dot voting for prioritization
How to know if pre-mortem was effective:
- Identified risks appear in risk register
- Mitigation plans are implemented
- Team refers back to findings
- Fewer surprise issues emerge
- Project success rate improves
- Create Psychological Safety: Encourage honesty without blame
- Diverse Perspectives: Include different roles and viewpoints
- Be Specific: Vague risks get vague solutions
- Assign Ownership: Each risk needs a mitigation owner
- Set Review Cadence: Revisit as project progresses
- Document Everything: Future you will forget details
- Follow Through: Identify risks is useless without action
- Balance with Optimism: Don't demoralize team