Principle · Defense and Kaizen

Pre-Mortem.

Source: Gary Klein, cognitive psychologist, in Sources of Power: How People Make Decisions (1998), MIT Press; popularized for managers in Klein's Harvard Business Review article "Performing a Project Premortem" (September 2007).

The Principle

Before a project begins, imagine that it has already failed. Then work backward from the failure, asking: what went wrong? Why did it fail? Whose actions or inactions caused the failure? The exercise turns the planning conversation upside down. Instead of asking "how will we succeed?", it asks "this failed -- explain how." The framing change unlocks information that does not surface in normal planning.

Klein's research showed that pre-mortems increase the ability to identify reasons a project might fail by about 30%, compared to standard planning processes. The mechanism is psychological: when people imagine a future where the project succeeded, they are biased toward optimism and tend to overlook risks. When they imagine a future where the project failed, they have implicit permission to surface concerns they would otherwise have suppressed for fear of seeming negative or undermining team momentum. The pre-mortem creates a structured time and place for that surfacing.

The technique has three elements. First, it is hypothetical-future framing, not abstract risk analysis. The team is told to assume the failure has already happened. Second, it is pre-decisional -- run before the project commits, not after problems appear. Third, the output is a list of causes that gets converted into preventive actions. A pre-mortem that does not change the plan was a wasted exercise.

Why It Matters Here

Defense and Kaizen is the team's anticipatory function. The CEO, the CMO, the Chief of Staff are all paid to drive forward. Defense is paid to look around the corner. Pre-mortems are the structured way Defense delivers that value: instead of a vague "have you considered the risks?", a pre-mortem produces a concrete list of failure causes the team can prevent before commitment. Without this discipline, Defense's anticipation stays in the head of one person. With it, the anticipation becomes a team capability.

Signals (When to Apply)

A new project, product launch, partnership, or strategic bet is about to commit resources
The plan has been written but not yet pressure-tested
Team enthusiasm is high and dissent has been quiet (high-confidence rooms produce blind spots)
The decision is structurally important (one-way door, large dollar amount, public commitment)
A recurring class of project has failed before in similar form

How to Apply

Schedule a 60-90 minute session before the project commits. Include the executives whose domains touch the project, plus Defense as facilitator.
Open with the prompt: "Imagine it is six months from now [or whatever the project's natural horizon is]. The project has clearly failed. Spend 5 minutes writing down every reason you can think of for why it failed. Be specific. Be uncharitable to the plan." Silence and writing first. Discussion second.
Collect the responses anonymously if possible. Group them into themes. Read them back to the team without attribution.
For each plausible failure cause, ask: what would prevent this? Convert each cause into a concrete preventive action, an owner, and a timeline.
Decide whether to proceed. The pre-mortem may surface so much risk that the plan is restructured, scoped down, or canceled. That is a feature, not a failure of the exercise.
Document the failure causes, preventive actions, and decision in writing. The pre-mortem becomes part of the project's working file. Six months later, the project's actual post-mortem can compare what actually happened against what was anticipated.
Do not let the exercise produce a thousand-item list with no action. Force prioritization to the top 5-10 failure causes that have meaningful probability and meaningful impact. Address those.

Examples

Applied well A team is about to launch a new product line in a category adjacent to the core business. Defense facilitates a pre-mortem. The team imagines the failure scenario six months out. Causes that surface include: (1) the new product cannibalized core-product sales without growing the total pie, (2) support costs were higher than expected because the new buyers had different expectations, (3) the new category attracted competitors who underpriced, (4) the team's attention was split and the core product slipped. The team converts each into a preventive action: track cannibalization weekly, staff support specifically for the new product, set a price floor with a kill criterion, time-box the senior team's attention. Six months later, two of the four risks materialized but were caught early because the team was watching for them. The launch ships successfully. The pre-mortem changed the outcome.

Misapplied The same team runs a pre-mortem on every routine project, including small content production and standard client work. Sessions become rote. Team members produce shallow, predictable failure causes ("we got busy," "we forgot a step") that do not change behavior. The exercise consumes 30 minutes a week and produces nothing actionable. The pre-mortem, applied to two-way doors that did not need it, became theater. Reserve the discipline for the projects whose failure would actually hurt.

When to Break It

For small, reversible projects where the cost of the pre-mortem exceeds the cost of just trying and learning. Use a lighter check ("what could make this fail?") instead of the full ritual.
When time pressure is genuine and the decision must be made faster than a structured pre-mortem allows. In that case, run an abbreviated 15-minute version, name the top 3 failure modes, and proceed.
When the project is genuinely exploratory (a small experiment whose purpose is to learn, where some failure is the point). Pre-mortems on experiments produce the wrong frame. Use a hypothesis-and-result frame instead.