“Whatever can go wrong, will go wrong.” We’ve all heard the sentiment behind Murphy’s Law. Many of us have said it at some point. But few of us actually act as though we’re worried about it.
A useful technique to be prepared for what can go wrong is to hold a pre-mortem. This is a meeting held at the start of a project or initiative in which stakeholders identify all possible problems that could impact successful delivery of that project.
The name comes from the idea of a project post-mortem, a meeting held at the end of a project in which stakeholders extract lessons learned from what went both well and poorly on a recently completed project.
Learning from problems at the end of a project is nice, but it benefits only future projects. It’s of no use to the current project.
A pre-mortem attempts to shift this learning to the start of a project, and stakeholders are asked to think of everything that could go wrong during the project.
For agile teams, the pre-mortem is at the other end of the work from a sprint retrospective but it covers an overall project or initiative rather than a single iteration. This relationship to the iteration retrospective results in the meeting sometimes being called a futurespective or pre-spective.
Who Should Participate?
A successful pre-mortem should focus on anything that could impact the success of a project. That means you should invite any stakeholders who can help either identify or solve those problems.
This will almost always mean you invite more than the development team, product owner, and Scrum Master or coach. Users, project sponsors, and representatives of other teams should participate. Consider also including those in important roles who look out for consistency and integrity of the product such as architects, designers, and database engineers.
Conducting the Pre-Mortem
Usually a Scrum Master or coach will facilitate the pre-mortem for an agile team. There are three distinct steps the facilitator should follow in conducting the meeting.
First, encourage the participants to create a list of all possible problems that could face the project. Usually this results in a list with too many items to effectively and efficiently address each.
So the second step is to prioritize and narrow the list to a top ten set of problems.
In the final step, participants identify solutions to those top ten problems.
Let’s consider each step in more detail.
Brainstorming Potential Problems
Start a pre-mortem by asking meeting participants to imagine every obstacle between where they are now and the successful delivery of the project. If a deadline or target date exists, obstacles to meeting that date should be part of the discussion. The opening question might be, “What could prevent us from successfully delivering this project in the next 90 days?”
From past pre-mortems, I can report that this might lead to a list of potential obstacles like this:
- Key resources are moved off the project
- Customers don’t respond quickly when we have questions
- The new hardware isn’t available when promised
- The four new hires aren’t as productive as quickly as we’d planned
- Hurricane season forces us to close the office for a week
- Management doesn’t uphold their promise to keep us out of all other non-critical work
On rare occasions, a group will struggle to come up with a list of potential problems. I’ve found it helpful to tell participants to imagine they are in the future and the product has been successfully delivered. I then ask what had to go well for us to arrive at that successful future.
This should result in the same list, in mirror image. It’s just a different way of thinking about it, and for some groups it’s helpful.
Selecting the Top Ten
At some point, the facilitator needs to call an end to the brainstorming. I suggest limiting this to no more than an hour. In many cases, far less time is needed. A skilled facilitator can recognize when creativity has died down, ask a couple of last questions to prompt for final issues, and then call the brainstorming over.
With a completed list of candidate issues, you now want to narrow it to the top ten obstacles to successful delivery.
There are many ways you can reduce the full list down to ten. For example, you could go through the list and ask for a yes/no vote on whether each item belongs in the top ten. After a first pass, see how many made the “most-wanted list” and then use subsequent voting passes to narrow it down to ten.
My preferred approach is to take a pass through the list, separating items into three categories:
- Definitely not in the top ten
- Maybe in the top ten
- Definitely in the top ten
If meeting in person, you can do this simply by moving each item (written on a card or sticky note) into one of three piles. When meeting online, I like using any cards-on-the-wall type of tool.
I’ll create a separate column for the categories above and then we’ll collaboratively move cards into those columns as shown in this figure. Take subsequent passes through the items until only ten items are in the “Top Ten” column or pile.
Identifying Triggers and Creating Plans
The third and final step is to decide what to do about the top ten. For each potential obstacle, have the assembled group identify:
- A trigger
- A mitigation strategy
A trigger is the signal to initiate your mitigation strategy. For example, one of the potential problems identified above was “the new hardware isn’t available when promised.” The trigger for that could be any one of the following:
- The hardware isn’t installed and available by September 18
- The vendor’s estimated delivery date is September 4 or later
- The purchase order isn’t submitted by August 1
The triggers above are listed in order of severity. The mitigation strategy should match the severity of the trigger.
For example, if you don’t have the hardware available by September 18, that’s a real problem. A mitigation strategy might be for the IT group (or whoever is setting up the hardware) to come in over the weekend to set it up.
On the other hand, if the purchase order isn’t submitted on time, mitigation strategies could be simpler: to order the hardware on a credit card and get reimbursed, or to pay for expedited shipping.
Monitoring Risks
It’s not enough to identify what might go wrong on a project; you have to keep an eye on the horizon to see if any of these problems actually occur. This is where the triggers come in.
Identifying triggers is useful: it simplifies monitoring these top risks. Instead of having to wonder if someone should act, identify actions and their specific triggers up front.
For a further step in monitoring the risks identified in a pre-mortem, you can also create a risk burndown chart and update it once per iteration.
What’s Your Experience?
What’s your experience been with project pre-mortems? Have you done one? Perhaps you called it something else. Was your pre-mortem helpful in identifying and avoiding project risks? Please share your thoughts in the comments below.
