« How to Pop a Change Bubble
“Taking a Break” Doesn’t Mean Delaying the Project »

Premortem: Imagining a Project Death

August 20, 2012 | Author: PM Hut | Filed under: Project Plan Development

Premortem: Imagining a Project Death
By Gayla Napier

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, 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 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.

Gayla Napier is an international consultant, researcher, and analyst with over 20 years of industry experience and 10+ years of consulting experience in: international change management, strategy consulting, business transformation, management consulting, development, implementing ERP (Oracle, PeopleSoft) and center of excellence initiatives. Her strength lies in her experience of taking organizations to higher levels of performance through the development and leadership of capacity building and organizational enhancement initiatives including; project management, needs analysis, process improvement & development, organizational development, performance management, instructional design, training design & delivery, group facilitation, strategic visioning, and teambuilding. You can contact Gayla via linkedin.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

This entry was posted on Monday, August 20th, 2012 and is filed under Project Plan Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

Perhaps another name for a pre-mortem is a project review? I’ve found that periodic project reviews also help assure project success. The scope may be a little broader than just a pre-mortem which may also have some benefit.

Ray Frohnhoefer wrote on August 20, 2012 - 9:23 am | Visit Link

Premortem Technique

Luis Bogaert wrote on May 19, 2013 - 9:42 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories