The Pre-Mortem Protocol: Engineering the Failure Out

The pre-mortem protocol

Optimism helps a project begin. It can also prevent a team from naming the weaknesses in its plan.

A pre-mortem creates room for those concerns before the consequences become expensive. The team assumes that the project has failed, then works backward to identify plausible causes.

The exercise is simple. Its value comes from making risk discussable.

Run the pre-mortem

Ask the team to imagine a specific future date on which the project has clearly failed. Describe failure in terms relevant to the work: the customer did not adopt it, the system did not perform, the economics did not hold, or the team could not deliver it.

Each person writes down the reasons they believe this happened. Independent writing matters because the first confident opinion in a meeting can narrow everyone else's thinking.

Then group the risks and examine them together.

Turn concerns into tests

A risk becomes useful when it changes the plan.

If an integration may not scale, test it early. If demand is uncertain, put a smaller proposition in front of potential customers. If one person holds critical knowledge, distribute it before that dependency becomes urgent.

Some risks cannot be eliminated. Record the warning signal, the person responsible for watching it, and the response available if it occurs.

Protect dissent

Teams often know more about a project's fragility than the plan reveals. People may hesitate to challenge a deadline, question a customer assumption, or admit that a design has become too complicated.

The pre-mortem gives those observations a legitimate place in the work. It does not replace judgment or guarantee success. It helps the team spend its attention while there is still time to act.