All Agile projects can fall prey to failure. The most heartbreaking failures come from surprises — those pitfalls in your path you never even saw coming.

To help our team avoid these traps and successfully complete more projects on time, we added a premortem stage to our project lifecycle. With a premortem, you can map the road ahead and see problems beforehand.

This article will dive into the premortem definition, explore what makes them so effective, and share tips for running premortems with your own projects.

What failure looks like

Each setback or unexpected problem adds time to your project. If the timeline of a project doubles or triples your estimates, then the first problem is the project timeline itself. A project that gets approved with its original timeline may lose priority and focus if it runs over, as the developers on the project may be needed somewhere else. Over time, you can end up starting a lot of projects with nothing to show for it. You waste time and money on failed projects, cripple team morale, and lose direction.

I experienced this first hand when I was learning how to be a lead software engineer here at Grubhub. We estimated that our SEO project would take three months. It actually took five as we designed three tables incorrectly, and it took two months to fix it — almost double our original estimate.

That was a major learning experience. Right after that project, Caryn Drange joined the team, and we talked about how we could avoid repeating the same mistakes. That’s when we came up with the idea to look for problems before we started.

What is a premortem?

A premortem is like a postmortem, except done before you start a project.

So what’s a postmortem?

In case you didn’t know, a postmortem is an Agile retrospective where you evaluate the success or failure of a project. The team asks questions like “How well was this project able to meet business goals?” and ”Why didn’t it meet those goals better?”

When leading a team through a postmortem, you want to find what worked well and what didn’t. Then, you can use that feedback to improve the management of future projects. This is key to a program of continuous improvement.

But a postmortem does little to increase the odds of project success. It happens too late in the life of the project — when it has already been completed — possibly after suffering delays or even complete failure.

The term “postmortem” comes from medical autopsies and literally means “after death” in Latin. If you’re conducting a postmortem, your project’s already died, and there’s nothing you can do to save it.

In reviewing a less than successful project, you need to have an extremely skilled facilitator. It turns out we’re humans and have these horrible things called feelings. But seriously, unless someone with a light touch guides the process, a postmortem can degenerate into a cycle of blame, with team members pointing fingers at each other. Once you start blaming problems on individuals, it can distract from the problems themselves and from the lessons your team can learn from them.

What if we could analyze a project’s failures before the project actually fails? What if our hindsight could be prospective instead of retrospective? We could create a forward-looking process instead of a backwards-looking one, a process that can improve our chances for success without having to pin those failures on specific team members. Our souls would be cleansed of all anger, anxieties, and defensiveness.

Imagining a future of failure

In a premortem, you and your team ask what could go wrong instead of what did go wrong. Instead of waiting for a failure to teach you a lesson, you try to avoid the failure in the first place. So many projects exceed their estimates because they run into unforeseen problems. A premortem is prospective hindsight, looking backwards from the imagined perspective of future failure. The more problems you can foresee, the more accurate your project schedule will be.

Here’s how you run a premortem.

1. Pick someone to facilitate the session. This person needs to know the project in great detail, and should be comfortable getting others to talk negatively about a project.

2. Next, get all of the stakeholders in a room. But how do you determine who holds a stake in your project? Ask yourself these questions:

• Who will be affected by the changes you make?
• What work needs to occur outside of my team so that the project integrates?
• How much work for the site reliability engineers (SRE) is there?

By getting all of your stakeholders together, you can avoid one of the biggest problems common to all projects. Can you imagine how frustrating it would be to do your part to finish your project — to spend blood, sweat, and tears making it perfect — only to have to wait an extra half-year to get into another team’s backlog because your work is not a priority for them?

3. Once everybody’s in the same room, ask them to imagine all the terrible things that could happen. We call this the “Brainstorm of Doom.” Your session facilitator should know a great deal about the project and keep the conversation moving. The team needs to be encouraged to be as cynical as possible, stating anything that could go wrong.

The hardest part of a postmortem for us is that we can’t discuss solutions at all — only problems. As problem-solvers, this can be tough. But it’s important to consider how the project can fail, as that failure will come in many forms. The solution depends on the various places that the failure could arise.

Here are a few problems we’ve come up with during premortem sessions:

• What if we produce bad data?
• What if any critical system or service goes down?
• What if the file we import has duplicate or corrupted data?
• What if a key team member gets sick for a period of time?
• What happens if a system stops responding or takes longer than we expect?
• What if the sitemap that we send to Google is empty?
• What if our project causes the database to grow too large?
• What if our cloud provider has issues?

4. Capture your session. Someone in the session needs to take notes on the conversation. This is good stuff — don’t lose it! To take notes in these sessions, I personally like using mind maps because they offer a visual view of the issues and their associations.

Create a future of success

After the ”Brainstorm of Doom,” it’s time to turn talk into action. Sort through all the potential issues and identify the ones that you need to mitigate. Turn those into tickets and tasks in your workflows. At Grubhub, we use JIRA to track and prioritize work. The system you use doesn’t matter — the work for each issue does.

Prioritizing tickets can be challenging for large Agile projects. We have found that using impact-effort matrices is a powerful way to focus developers’ precious time on the most important tasks. They allow us to identify which actions make the greatest difference for the least work.

Finally, at Grubhub, we have been using Gantt diagrams to estimate projects and manage dependencies and expectations. Thus, those problems that you would have discussed and discovered at the end of a project become predictable and manageable. They become part of the total project timeline. No surprises. Win-win!

Final words of advice

Postmortem sessions are a powerful tool, but they do not prevent the current project from failing. Premortems flip the paradigm, making the team imagine possible failure scenarios to prevent or mitigate those problems. This creates a path to success with predictable and manageable project timelines and expectations, which in turn increases team efficiency and morale. Try it out and share your experience in the comments below.