Redirecting to https://www.makingdatamistakes.com/premortem/ - click if you are not redirected.
In the past, running a Premortem has been the single most helpful exercise I’ve found for succeeding at complex, risky endeavours.
I’ll tell you a true story about my first Premortem. I’d just joined a company as the new CTO, and we had been invited to be featured in Apple’s latest iOS launch in a few months’ time. We had no control over the event, and if we weren’t ready for it we wouldn’t be included. It involved designing and building a mobile version of an existing product in about four months flat. On top of that, the CEO was determined to use this opportunity to make a number of changes and improvements to the product, most of which were being designed at the same time.
Soon after I’d joined, I’d used the honeymoon period as a new exec to highlight some major team problems, to have a few difficult conversations, and to make critical changes. But I was feeling that there were only so many problems I could highlight before it would seem that I was making excuses and lose the CEO’s trust. So we’d discussed the list of necessary features for the product launch, and we’d agreed to strike off a few of them - but the CEO considered the remainder to be absolutely essential.
Fast forward a couple of months and I was panicking. It was crystal clear to me that we were simply not going to be able to release a working product in time, let alone with all the features we’d agreed on. So the CEO and I went for a walk. We told a story together out loud about a potential worst-case future that hadn’t happened yet, picturing the Apple launch event happening in slow motion, with nary a mention of our product after a disastrous demo the week before. We imagined having to explain what had happened to investors, and the feeling of walking into work the next day knowing we’d blown it. I think we felt almost physically sick at what a disappointment that would be. Then, with 20-20 counterfactual hindsight, we listed all the things that had gone wrong to cause that outcome, and what we could have done differently. Finally, we walked back from the brink, and it suddenly became very easy to make decisions about what we’d be willing to change in order to avoid that outcome.
We agreed on many changes together as a result of that discussion, including clarifying which features really were essential. The next month was brutal for the whole team, because it was still an extraordinarily ambitious goal that we’d set for ourselves. And even on the dress rehearsal the day before the deadline, the app crashed within the first 30s of the demo. But ultimately, the demo was a success, we were featured, we hit #3 in the US iTunes Health & Fitness App Store, and we were on to the next chapter. We also did some soul-searching right afterwards about what kind of company culture we wanted to have, and avoided ever going through a collective experience like that again.
So I’m not joking when I say that a Premortem refocused the hardest death-march I’ve been on, and another Premortem years later was a key step in planning for a complicated (and ultimately successful) major fund-raise. If all goes well, it’ll help highlight your biggest fears, and proactively figure out steps for how to defuse them.
In short, this is how I run them now:
Gather a couple of other core people/project leads with complementary expertise and the power to make changes. Allocate 2 uninterrupted hours (though you might not need all that time once you start to get efficient at them).
Sit down and read the above Guardian article through together at the beginning of the session.
Have fun telling the nightmare story collectively. I usually set them at the next major milestone, perhaps within the next 6 months or so. Make it specific and vivid, e.g. ‘The CEO of X is on stage announcing their partnership in October with your major competitor’ or ‘We’re out of money and don’t exist, and you’re back to working at your previous job you hated.’
With 20-20 counterfactual hindsight, list all the reasons for failure. Set a timer for 15 minutes or so, and separately in silence each scribble down as many potential reasons why this terrible future came to pass, e.g. ‘Their CEO tried it out and hit a bug and they lost faith in us’, or ‘The lawyers axed the project because of regulatory hurdles’. I usually use either Google Docs or post-its to make the following phases easier.
Race through everyone’s items out loud quickly. There will be duplicates and related issues – as you go through them, place them into groups.
Then, for each group of issues, ask ‘what could we do to fix/de-risk this?’. [Maybe do this in silence individually first too]. You’ll start to see that there are a few things you could do that will help considerably de-risk multiple issues at the same time. Assign one person to be responsible for each approach you agree to act on.
By this point, you should have felt like you’ve looked into the abyss, but come out the other side and achieved a measure of catharsis. There’s something about the perspective you get from doing this exercise that makes it much easier to make hard choices.
Set a date to revisit in 6 weeks, to make sure you actually addressed the risks you’ve just identified, and see where things stand.
I’ve used Premortems most successfully in a couple of scenarios, e.g.:
Before a big launch/delivery/event, to expose all the things that could go wrong, and de-risk them.
As a way of making critical prioritisation decisions, e.g. when the Product Manager refused to take anything off the ‘essential backlog’. This helped them see that they’d rather meet the really important hard deadline missing a few features, than completely whiff the deadline because we were considering all the features to be essential.
It seems to help for there to be a particular event or deadline that you’re focused upon, with clarity about what a win or loss would look like. When I tried running a Premortem in a general way to try and improve overall team performance, it fizzled somehow.
It works best if you come up with the 20-20 counterfactual hindsight reasons for failure quietly in isolation rather than out loud - see Quiet Brainstorming.
Make sure there’s enough time. I participated in a Premortem that spent all the time highlighting reasons why things could fail, and ran out of time to consider the changes we could make to turn it around. Everyone left feeling enormously dispirited, and we didn’t discover or make the changes we needed to.
Finally, there needs to be trust. I tried running one in a group where there wasn’t trust. One of the key people involved didn’t show up, which meant that we didn’t have their input or their buy-in to potential actions. The other didn’t really want to consider the worst-case scenario, and we were both wary of saying what we really thought. Perhaps it’s no surprise that the worst-case scenario eventually came to pass.
Based on: