Execution

The pre-mortem: the meeting that saves projects

Post-mortems explain why things went wrong. Pre-mortems prevent it. The two-hour exercise that changes project outcomes.

A post-mortem happens after the project has already failed. A pre-mortem happens before it starts. The exercise is simple and uncomfortably effective: assume the project has failed catastrophically six months from now, and the team has gathered to write its obituary. What killed it?

Why imagined failure beats predicted failure

People are bad at predicting risks because predicting risk feels like pessimism, and pessimism is socially expensive on a new project. Imagining a failure that has already happened gives permission to surface the risks that would otherwise stay unsaid. The team uncovers in two hours what would have taken months of bad results to learn.

How to run it

Frame the scenario: "It is six months from now. The project has been declared a failure. We are writing the post-mortem. What happened?" Have everyone write their version silently for ten minutes, then share. Cluster the themes. The biggest cluster is the biggest risk. Build the project plan to mitigate the top two or three clusters.

When to use it

At the start of any project where failure would be costly. Before a launch. Before signing a contract that locks you in. The exercise feels like overkill until you have done it once and discovered the risk that would have killed you.

Takeaways

What to do with this

Related

Keep reading

Tell us where the work gets hard.

Whether it is a tangled workflow, a product idea, or an operation that has quietly stopped scaling, we would like to hear it. No pitch deck required.