No one starts a project with the intention of ending in spectacular failure. About the only saving grace of most startups is that their failure is less-than-spectacular. Even in well-established businesses, projects routinely run over-budget, come in late, and fail to meet the team’s (and management’s) expectations.
There are many ways to avoid this fate, but one of my favorites is the Project Pre-Mortem.
To Avoid Failure, Plan for It
Project post-mortems have been stock in trade for many software development teams for decades, and the bone-cutting and delightfully dry analysis can make for wonderful late-night reading.
Post-Mortems are rarely effective at their stated aim of identifying where a project went wrong so that future errors can be avoided. They are excellent at meeting their unstated aim, which is to assign blame for the failure and perhaps provide the team with a useful way to blow off steam after a frustrating few months (or years). At the very least, everyone gets pizza.
Agile software development has contributed to a decline in the need for comprehensive post-mortem analyses, in part because the short, iterative development cycle prevents large problems from accumulating, and daily stand-ups and Sprint Planning Sessions provide frequent opportunities for team members to raise and resolve issues before they become big problems.
All the more reason to kick off a project with a Pre-Mortem, where the team comes together to identify all of the areas where the project might go wrong before it happens.
Before we dive into how to conduct these sessions, I want to address a few possible reasons why this might not work:
- “You can’t see the future, so a pre-mortem isn’t very useful.”True, you don’t know what you don’t know. But most teams do know of a few reasons why a project might go off track, or why it has in the past. Getting this out in the open early lets you spend your precious decision-making time dealing with unforeseen problems.
- “The term 'Pre Mortem' is morbid, and it sounds like someone is going to die.”If this is really a problem, call it a “Project Success Workshop”. Usually, the problem isn’t what you call this activity, it’s the fact that people don’t like thinking about failure. Again, that’s ok; trust in the fact that tackling difficult issues ahead of time while they’re merely possibilities is easier than tackling them when they are staring you in the face.
- “We’re a nimble, Agile, scrummy-team, and we can handle the unexpected.”You know who else is an agile, scrummy, nimble team? Navy Seals. And guess what: they plan extensively. Repeatedly. With multiple backups. And they don’t leave decision making for when the unexpected occurs.
So, three reasons why a Pre-Mortem might not work, and three ways to plan around those objections. See what I did there? I Pre-Mortem’d the idea of a Pre-Mortem. So very meta.
So, How do We Actually Plan and Execute a Pre-Mortem?
Luckily there have been lots of guides on how to run a Pre-Mortem, most of which draw extensively from the Gamestorming book which popularized the idea.
The basic premise is simple: gather the main project stakeholders together for 60-90 minutes, and collectively come up with a list of things that could go wrong during the upcoming project, then list out the consequences of each potential problem. For example:
Problem
“This project is going to require weekly meetings with the executive sponsor, who is often traveling for work.”
Then we try to pinpoint what consequences exist if this problem occurs:
Project Risk
Medium
Details
“We may get stuck on specific decisions if the project sponsor isn’t available.”
Potential Negative Outcome
“The team might have to pause work. We will lose momentum. We might also miss our project deadline or run over budget.”
Finally, we work to identify what we can do to prevent the problem, or fix it, and who should take responsibility for keeping watch over the potential issue we’ve identied.
Preventative Actions
“We’re going to make sure that there are always at least 2 people other than the Executive Sponsor who can make critical decisions.”
Mitigating Actions
“If none of the three Key Decision Makers are available, the team will jointly decide on the best course forward.”
Who’s Responsible
Dwayne "TR" Johnson
It is also possible to do this asynchronously or with a distributed team, using a shared resource like AirTable or Google Sheets (see below for an free tool you can use.)
Here are three additional guides to running these kinds of Project Pre-Mortems:
- How to Run a Project Premortem Exercise with Your Team (Atlassian)
- Performing a Project Premortem (Harvard Business Review)
- How to Run a Pre-Mortem and Save Your Project From Inevitable Disaster (Tom Hewitson, on Medium)
If This Seems Like a Lot to Keep Track of, We’ve Made it Easy/ier
Want a way to gather this from your team? We created a handy AirTable that gives you a place to keep all of your Pre-Mortem Project Risk Factors, and a Form to use to gather ideas from the team.
(To use this, just use the “Copy Base” link in above.)
As the Navy Seals say, “Two is one and one is none.” Plan better, and your project stands a much greater chance of being a success.
Want More? Sign up for Access to Great UX Research Templates and Guidance for Building your UX Research Practice