Premortem: Imagining a Project Death

Does the following development seem familiar? A project is started, endorsed by stakeholders, driven by decision makers, approved by executive management, kicked off with a flourish, worked diligently by a project team, only to result in an end that does not meet expectations—or worse failure?

Why does this happen? There are at least two possible explanations: 1) We tend to start and run projects the way we always have—not only during the planning stages but also across the project lifecycle—project members are reluctant to express reservations about the work-ability of a plan: they keep silent because it can be dangerous to oppose what the project management office has decreed is the right path. 2) Intellectual barriers play a role too. Individuals and groups may be biased[1], when they have worked hard on a plan. We can become psychologically committed to the idea of our project success, be overconfident, and therefore blind to some of the project risks.

As organizations, we do not like to fail. Most projects are followed by a post mortem activity where we seek to identify the reasons for failure or what we might do better the next time around. More often than not the results of the post mortem effort are relegated to a file on someone’s laptop and never referenced again. What would happen if we flipped this process and conducted a ‘Premortem’ event instead?

Author Gary Klein suggests that an organization should conduct a Premortem rather than a postmortem. As a risk mitigation tool, the Premortem attempts to identify risks and issues at the beginning of a project. By asking our project team to engage in critical thinking upfront we can reduce the chance of project failure.

Conducting a Premortem is low cost and potentially has a high payoff. With a good facilitator you should be able to conduct a Premortem in 1 or 2 hours; here are some suggested steps:

1. Determine how long after a project is finished it might take you to determine the project’s success or failure.
2. Ask your team to imagine that that the project is now complete and those weeks or months have passed. Have them imagine that the project was a debacle and has resulted in disastrous consequences. What might have caused this to happen?
3. Ask each team member to suggest 7-10 reasons for failure. Make sure your team members know it okay to identify reasons that might seem impolite or sensitive. Reasons might come from a numbers of sources such as:

• Inadequately trained and/or inexperienced project managers
• Failure to set and manage expectations
• Poor leadership at any and all levels
• Failure to adequately identify, document and track requirements
• Poor plans and planning processes
• Poor effort estimation
• Cultural and ethical misalignment
• Misalignment between the project team and the business or other organization it serves
• Inadequate or misused methods
• Inadequate communication, including progress tracking and reporting

Once everyone has their list of reasons for project failure…

1. Begin with the project manager or team leader and have everyone voice one reason on their list. You should repeat the cycle around the room until everyone has voiced all their reasons and they have been written up on a whiteboard or flip chart.
2. After you’ve thanked the team, gather and prioritize the comprehensive list of reasons that were generated.
3. You now have a wealth of information to strengthen your project plan
4. By prioritizing the areas of greatest concern, you can incorporate ways to avoid or mitigate potential causes of failure.

The Premortem activity allows people to overcome groupthink[2] by giving them permission to search for potential problems they might be overlooking. In sum, by tasking a team to creatively imagine that the project has already been implemented and failed miserably we increase the team’s ability to correctly identify reasons for negative future outcomes.

References

Gary Klein. 1998. Sources of Power: How People Make Decisions. MIT Press.