Plan your failure before you start

How pre-mortems surface the risks estimation hides

This is the third in an unintentional series about the risks surrounding estimation. I’m certainly not a member of the #noestimates crew, but there are anti-patterns associated with forecasting that we should seek to avoid.

Estimates shouldn’t be treated as commitments.

The planning fallacy means all estimates are fundamentally flawed.

But teams still need to estimate, and estimates still have value in enabling organisations to understand cost-benefits and trade-offs.

Trying to get ‘better’ at estimation or investing heavily in planning overhead are seductive traps that don’t actually improve forecasting. They don’t help to surface the risks and blind spots that estimators commonly overlook. One thing that can do this is a pre-mortem.

What’s a pre-mortem?

Looking back is well-established as a way for teams to learn and improve. Retrospectives (or post-mortems) are a key tool for teams to inspect and adapt their practices, learning from when things have gone wrong.

Pre-mortems use a similar approach, by asking teams to imagine all the things that could cause them to fail before they start the work. This isn’t just playing around with timelines. It’s a powerful way of leveraging the very biases that make estimations flawed.

Estimates are by necessity best guesses about the future. People tend to forecast optimistically, underestimating difficulties and discounting obstacles. Even having experience of similar issues, and having encountered substantial difficulties in the past, isn’t enough to prevent people using the happy path to estimate effort. Having the team forecast failure instead of success offers better protection.

A pre-mortem is a structured exercise, best suited to complex or novel work where a team has little expertise. It’s a forced perspective shift that helps surface risks that estimation usually misses.

The process is straightforward. After creating an initial estimate, the team imagines a future where they’ve failed completely. “It’s [x] months from now. We started this work and it’s been a disaster. We have failed utterly in our objective. What went wrong?”

The team lists everything that could have gone wrong, maps these into risks, discusses mitigation strategies, and then, crucially, revises the estimate in light of what they’ve surfaced.

Why are they important?

Pre-mortems work because they exploit how the ‘inside view’ functions. In normal estimation, the inside view is optimistic - the engineer imagines the specific steps they’ll take to complete the work, and underplay the risks that they’ll get distracted or that something will go wrong. Historical or statistical evidence (the ‘outside view’) feels abstract and irrelevant, so any deviations from the inside view tend to be ignored.

Pre-mortems don’t waste time trying to get the team to take history or statistics more seriously. Instead, they hijack the inside view and point it at failure. “Imagine having failed” is every bit as vivid and concrete as imagining success. It surfaces completely different information. The team still gets to think in specifics, but now those specifics are risks rather than happy paths.

There’s also a social dynamic at play. In normal estimation, people can feel pressure to sound confident and capable. Voicing concerns can feel like admitting weakness or cynicism. People can worry that it appears that they’re not supporting the team.

But when the facilitator asks “what went wrong in our failed project?”, pessimism becomes collaborative rather than individual. Everyone’s imagining the same disaster, so naming specific risks feels safe.

There are no guarantees that this will completely remove the planning fallacy, but it empowers the team to consciously consider the risks they may not have thought through when initially estimating the work.

What does it look like in practice?

Let’s imagine that a team estimates the effort to migrate a legacy authentication system at six weeks. In the pre-mortem, they imagine it’s six weeks later and the project has failed. They are nowhere near achieving their goal. What happened?

One developer immediately says ‘The documentation for the old system was out of date. We made bad assumptions that didn’t match current functionality.” Another adds “We were blindsided by downstream impacts in the monolith - we just didn’t foresee all of the dependencies we had.” A third engineer states “The company changed its policy about using the third-party identity provider we had identified as our solution mid-project, meaning we had to start again with a different provider.” The QA engineer points out “We didn’t have a test environment that properly mimicked production, so we didn’t capture all of the regression bugs before we deployed.”

None of these concerns informed the original estimate. These are no longer abstract risks. They’re specific, concrete failures the team now realises that they have to account for. The team revises their estimate to 10 weeks and adds three mitigation strategies: audit the existing system before starting, create a proper test environment, and add buffer for third-party dependencies.

What can go wrong?

Let’s pre-mortem the pre-mortem! Pre-mortems can fail in predictable ways, including framing, operating at the right level of detail, and inaction. Let’s take these in turn.

Framing

Asking “what could go wrong?” won’t shift the team’s mental model. Make sure to frame the pre-mortem with “We have failed. What happened?” This gives everyone permission to think of scenarios and risks, and to be pessimistic. Asking “what could go wrong?” doesn’t go far enough in pushing the team out of the optimistic inside view. They need the vision of their own failure to help them see how much trouble they can get into.

Too little detail

Another cause for concern is if the team only offers superficial risks when challenged about how they failed. If the team isn’t willing to get into concrete examples of where things can go wrong, then the optimistic psychology of the original estimate won’t be challenged.

The facilitator of the pre-mortem needs to drive the team toward specific scenarios. “The requirements might change” is an acknowledged risk of every initiative everywhere, and won’t challenge the team’s initial thought process. “We overload the API and can’t deliver acceptable performance without upgrading our infrastructure (which we know is outdated)” is the kind of situation that an engineer can absolutely see themselves in.

No action

If the team is willing to engage in considering scenarios that surface major risks, but then aren’t given the opportunity to alter their estimate in a blame-free way, not only have they wasted their time, they’ve had their psychological safety undermined. Estimates are always wrong. It must be safe to revise them.

When shouldn’t you use them?

Pre-mortems are most valuable for complex, novel, or uncertain work. For routine tasks or well-understood problems, they’re overkill. If the team has done something similar five times before and it always takes two weeks, a pre-mortem won’t add much value. If the team still insists on estimating at three or four days, use the real data you have.

Save pre-mortems for the work that worries you.

Reality always wins

Pre-mortems don’t eliminate the planning fallacy. Even after a pre-mortem, teams will still underestimate. What pre-mortems do is surface specific risks that would otherwise remain invisible until they bite you. In the best case scenario, you’ll get an estimate that hews closer to reality. In the worst case, you’ll have a list of things to actively monitor and mitigate.

Think of pre-mortems as harm reduction, not a cure. You’re still going to be wrong. You’re just going to be slightly less wrong with mitigation strategies in place.