Want a Successful Project? Try a ‘Pre-Mortem’

shutterstock Pressmaster

Many companies host post-project meetings to discuss what worked and what didn’t, a process known as “post-mortems.” But instead of waiting until the end of a project to figure out what might have gone wrong, how about holding “pre-mortems,” in which all aspects of planning are discussed before everybody gets to work? The latter could help avert real failures.

Click here to find project management jobs.

With software projects, a pre-mortem might work something like this:

At the very beginning of a project, make sure to block some time with the team to “spring forward.” Collectively imagine that it’s one month after the release of the software you’ve gathered to build. Make the assumption that the effort had the worst possible outcome, and write a short story about why the failure occurred. It may look like this:

The rollout was a nightmare. By the middle of the second week after launch, still over 500 support tickets were unresolved. The development team was completely overwhelmed trying to repair bugs and support/triage performance issues. Transactions were delayed or timing out because the assumption was made for no more than 10 concurrent transactions, when in fact real-world use called for 100. Additionally, many of the features were difficult to use and unintuitive, so the training team had to create large documents to explain how to perform simple tasks.

Upload Your ResumeEmployers want candidates like you. Upload your resume. Show them you’re awesome.

After that’s complete, do the opposite: Create a short story where everything turned out to be a spectacular success. What led to that success? Using both stories to identify roadblocks, the team can strengthen the requirements process. Here are some of those common roadblocks:

  • The requirements should be able to specify the software’s minimum quality, including performance goals based on expected number of concurrent users and transactions, etc. Many teams fail to set a bar for minimum quality.
  • The requirements should include aspects of usability and intuitiveness, in order to ensure that users can easily learn how to use the system, and that a dozen mouse clicks aren’t required to complete a single task. Many teams neglect to make software as streamlined as possible.

One of the many benefits of pre-mortems is that they can help surface any non-functional requirements that could become a problem if not addressed in the specification. It’s better to get everything possible on the table in the beginning, rather than when everybody’s frustrated and exhausted at the end of the project.

There is plenty of evidence to suggest that looking beforehand at what could go wrong can enable success on complex and high-uncertainty projects.

Related Articles

Image: Pressmaster/Shutterstock.com

2 Responses to “Want a Successful Project? Try a ‘Pre-Mortem’”

  1. This is a really great idea! I’ve been trying to push myself and my projects into risk management, but it’s hard to get individual team members to look on that as anything other than being a tattletale, even though the bad things haven’t even happened.

    Giving them a glimpse into a dystopian future that can be prevented might really give them a chance to see things in advance.

    I think I’ll try this one. Thanks, Mr. Gara.

  2. Patrick Purtell

    This is pre-mortems seems similar to what I have done called gating. I have 8 checkpoints during the life of a project from initiation through to post deployment. We review what has been done, what hasn’t as well as identifying any potential issues coming down the road. By being pro-active like this, we have had the luxury of telling management of issues BEFORE they happen. I have found that management has lot of respect for identifying issue up front, rather than dealing with them afterwards in the middle of a crisis.