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.
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.
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.
- Four Lessons in Project Management From Healthcare.gov
- The Key to Steve Jobs’ Management Genius
- Turbocharge Your Time Management With These Tips