How to Avoid Project Failure With a Premortem

Only 39% of all IT projects succeeded in 2012. If that number seems alarming, consider this: 68% of IT professionals believed their project would fail right from the beginning. Of those people, how many actually voiced their concerns before work kicked off? In a team of 20, you're probably looking at one or two — if any.

There are several reasons why team members stay quiet at the start of a project rather than surfacing their doubts:

• They want to avoid appearing negative.
• They worry their concerns aren't valid and that speaking up might make them look inexperienced.
• They feel like they're manufacturing a problem before anything has actually gone wrong.
• They simply lack the confidence to speak up during team meetings.

Whatever the reason, it's clear that projects benefit from a structured, open forum where each team member can express concerns and contribute their knowledge and experience freely.

Most teams do examine potential risks during the planning stage, but this analysis tends to focus on what might happen. To fully account for all possible failure modes, teams need to go further — not just identifying what could go wrong, but analysing what did go wrong. The challenge is obvious: how do you analyse a failed project before it has even started?

The answer is prospective hindsight, applied through a method called premortem.

What Is a Premortem?

Anyone working in IT or software development is familiar with the postmortem — the session held after a project wraps up, in which the team identifies what succeeded, what failed, and what lessons can be carried forward.

A premortem flips that exercise in time. Rather than looking back after the fact, a premortem asks teams to pretend the current project has already failed, then work out why. It is typically conducted after the project plan has been released or during the development process itself.

A standard premortem session opens with the project manager announcing — in no uncertain terms — that the project has failed. Each team member then writes down every possible reason they can think of for that failure. Once everyone has finished writing, team members take turns reading their reasons aloud.

The project manager (either independently or together with the team) then works through all of the reasons collected, assigns each one a probability score, and identifies adjustments that could improve the project plan and reduce exposure to those risks.

Because a premortem asks teams to analyse what did go wrong rather than only what might go wrong, it can increase the chances of uncovering potential failure reasons by as much as 30% compared to conventional risk analysis.*

Benefits of Running a Premortem

A postmortem on a failed project yields lessons that inform how the next project is handled. A premortem offers the same kind of insight — but early enough to act on it. Teams can address the mistakes they "made" in the hypothetical failed project before those mistakes have a chance to occur in reality.

Additional benefits include:

• Confidence in speaking up. Team members can raise concerns and back them with concrete reasoning, rather than suppressing doubts.
• Shared knowledge. Everyone has a structured opportunity to draw on their experience with both past successes and past failures.
• Stronger team morale. Open dialogue and mutual transparency tend to build trust across the group.
• Broader participation. Because all team members are expected to contribute, quieter or more introverted contributors are actively encouraged to share their perspective.
• Reduced groupthink. By surfacing dissenting views individually before group discussion begins, a premortem limits the tendency for teams to converge prematurely on a consensus that nobody privately believes in.

For risk identification to be genuinely thorough, premortems need to be treated as a standard part of the planning process — not an optional extra. As the saying goes, (prospective) hindsight is always 20/20.

* Back to the Future: Temporal Perspective in the Explanation of Events — Deborah J. Mitchell, J. Edward Russo, and Nancy Pennington, 1989.