Most of us know that a post-mortem is done after someone dies. A pre-mortem isn’t done on a person, but instead on a project or – for our team – just before embarking on our private beta. Thankfully everyone involved is also still alive and kicking.
The intention of the pre-mortem is to imagine a future state when the project you have worked on has already become an unmitigated disaster or glorious success. Then work out how it got there.
Why do one
- nobody wants to be responsible for a disaster – if you can avoid this, it’s worth hours of your life
- you might have overlooked opportunities that are out there – discover them and go make them a reality
- you can be so close to something that it can help to look at your plans from a new perspective
- it forces you to confront issues before they destroy you and the project further down the line
- it helps you create practical actions that can be assigned to people to work on immediately
- it’s fun and creative
Who to invite
Firstly the team working on the thing. I’d definitely advocate also casting the net even further. It’s valuable to get people from different perspectives. Consider inviting stakeholders, people on the outskirts of the service, or people you know in an organisation. The wider your reach, the more likely you’ll find out about things you’ve overlooked.
You could also invite some real-life users. We didn’t do this but it would be fascinating, and I’d love to hear the results.
How to run a pre-mortem
This is a summary of how I ran it (the methodology was inspired from the Atlassian playbook, with a few tweaks):
A few weeks before
We sent out the invitation to the team and wider people in the organisation. We booked a big enough room to accommodate everyone, and scheduled it for 2 hours.
24 hours before
I sent invitees a few questions for them to consider beforehand. This was to get them in the right frame of mind for the pre-mortem. The guide suggests:
- what could slow us down or make us miss our deadline for launch?
- what are we already nervous about?
- where did you discover blind spots on past projects?
- how quickly can we respond when something goes wrong?
- who could own each of our biggest risk areas?
- think about where you might be able to over-achieve – if the project turned out to be a ground-breaking success, what might that look like?
These worked well.
On the day
Intro (5 min)
With everyone in the room, I pitched roughly what we’d be doing and why. I then encouraged them to set aside daily tasks and get ready to dive deep into their imagination. No suggestion was silly – we wanted to go to the lowest lows and highest highs.
Context (5 min)
I then set the context. I picked a date and told the team to fast-forward to winter 2020, a world where our newly revamped service has been live for 6 months.
Splitting the teams: failure vs success (30 min)
I then split them into 2 teams. One had the job of envisaging a world where the service is an unmitigated disaster. The worst failure possible. I asked the team to write down all the warning signs we could have ignored, all assumptions we believed in that were misguided, and what else could wreak havoc on our efforts.
The other team had the chance to think of a glorious future. The team and service had gone above and beyond, users loved the service and we were winning accolades for our work. I asked them to write down how we had bettered lives and what unexpected successes had we caused thanks to our fabulous work.
Both teams went off to find more comfortable seating and away from the hot confides of our meeting room to do this part, which worked well. Both teams scribbled their thoughts on post-its.
Scrutinising each other's version of the future (20 min)
Next I called the teams back to the meeting room to share their thoughts.
The first team shared the optimistic view of the future and the other team pushed them to higher heights and thought of other signs of success we could encounter.
We then heard from the failure team and pushed ourselves to create more and more disastrous scenarios.
Vote (10 min)
Next up was to dot-vote what people thought were the top 3 risks and opportunities. I gave everyone 5 votes and they could use them anyway they wanted (only requirement was to vote for at least one risk and one opportunity). If someone wanted to vote 4 times for a certain risk and once for a opportunity, then no problem.
I encouraged the team to vote for things that we have influence over. One of our risks was that one of our offices would suddenly implode and wouldn’t exist anymore. While obviously problematic, we don’t have much control over this so was out of favour for things we could mitigate or take action on.
Coming up with practical next steps (30 min)
We now had 3 top risks and 3 top opportunities. It was time to take these away and think of all the steps we could take to mitigate the risks and seize the opportunities.
I asked the team to make these as specific and clear as possible. Broad statements like “email the minister” were not allowed – we would need to add when this should happen, what we would want to convey, and the outcome we want from that exchange.
Sharing next steps (10 min)
Finally, I asked the team to return to the meeting room and share the actions and ask for any extra input.
Wrap-up (5 min)
Normally you’d then assign specific tasks to people but we didn’t do this was because we were out of time – people had to get trains and there were people in our group who were not in our team. Instead we agreed to assign tasks at our team planning next week. We also promised to have a thorough re-visit of what we produced on the day in 6 months time to see if we had done the things we’d thought about and if we could think of extras.
Retrospective (5 min)
After thanking the attendees I then asked for instant feedback and waved goodbye to everyone.
After the workshop
I took responsibility for writing the post-its. Our team uses Trello, so I created a couple of new columns, one for the top risks and opportunities we voted for, and the other for all the actions we came up with. I linked the action cards to the relevant risk/opportunity card.
During planning we went over each action and brought some into the current sprint. We’ve already taken action on a couple, which is brilliant. I'm chuffed that we are taking steps towards success and avoiding risk.
Each planning session we’ll be keeping an eye on which tasks we can do, and make sure we are not doing anything we identified as bad practice that could lead to failure of the service.
Feedback
The feedback from the retrospective was very positive. Attendees:
- enjoyed taking a new approach to thinking about their work
- liked using their imagination
- liked getting away from their day-to-day tasks
Things to think about for next time:
- explain at the beginning of the event that they should keep one idea per post-it to help playing back to the group and for the voting stage
- switch up the teams after the votes so people could sample being in both success and failure teams
- if you have the luxury of time, perhaps do a little activity to get the creative juices flowing with participants (earlier in the day we had done the paperclips exercise, which worked well)
- get someone else to assist with running the event so you can dedicate more time to helping teams when they are coming up with ideas instead of being split across 2 teams
Should I do one?
Yes, definitely. At worst your team breaks free of their daily duties for 2 hours to think about the service and reflect on risks from a new perspective.
It energises the team to take actions against the holes in your plan and identify opportunities you might be overlooking.