The archive · Work & Ways of Doing · Operational decision · 2007–2019
Premortem: assume the project already failed, then list why — before you start
Gary Klein's 2007 trick makes failure safe to discuss in advance: teams imagine a project has already died and write down the reasons why.
Gary Klein (Klein Associates)
What it had to solve
Projects fail at a spectacular rate, and one reason is that the people who know the risks do not say so during planning: raising doubts in front of colleagues feels like attacking the plan or its author. Gary Klein, a decision researcher who had spent his career studying experts in high-stakes settings, published a two-page fix in Harvard Business Review in September 2007.
How it works
Gary Klein spent his career studying how people make decisions under pressure, and he kept seeing the same pattern: projects failed at a spectacular rate not because nobody knew the risks, but because the people who knew them did not say so during planning. Raising doubts felt like criticizing the plan — or the person who made it.
Klein's fix, published in Harvard Business Review in September 2007, flipped the meeting's psychology. The team is told the project has already failed and asked to write down the story of why. Because the failure is a given, listing its causes is not criticism or disloyalty — it is just explaining the obvious. The method runs the logic of a postmortem before the project dies, which is where its name comes from.
The ritual spread as a standard management technique. Teams silently generate plausible failure reasons, group them, vote on the biggest threats and turn the top risks into action items with owners and deadlines — the shape Atlassian's Team Playbook later packaged into an hour-long play with templates. Its appeal is the same in every setting: it makes the pessimistic conversation the first agenda item instead of the last.
Why it lands
- Prospective hindsight removes the social cost of dissent: once failure is a given, listing its causes is explaining the obvious, not attacking the plan.
- Writing reasons privately first keeps confident voices from drowning out quieter skeptics before their ideas exist.
- An hour of failure rehearsal produces concrete threats that become action items, so optimism is tested before resources are committed.
- The technique needs no consultants or software — paper and sticky notes are enough — which is why it spread across industries.
What it did
The HBR piece became a standard reference in project management, and the technique spread far beyond Klein's world of high-stakes decision research: Atlassian packaged it as an official team play with templates, and distributed teams adopted it as a routine pre-launch ritual for building trust and clarifying roles as well as for catching risks.
What you can take
Make the pessimistic conversation the first agenda item: by treating failure as already true, a premortem lets people list risks without accusing anyone, so the plan hardens before the work starts.
Since then
The premortem became a standard item in the project manager's toolkit rather than a one-off magazine trick. Atlassian folded it into its Team Playbook with step-by-step instructions and templates, distributed teams ran it to build trust before their first launch, and safety-oriented fields adapted the idea into their own toolkits. Its durability comes from its economy: no software, no consultants, no data — just an hour of imagining the worst while there is still time to do something about it.
Sources
spotted an error? The archive wants to know.
Your turn
You just read one. Describe the brief you are staring at, and see who has been given the same problem.
Free account · 3 free questions · no card