Premortem: One of the most powerful tools for business analysts

Pretending that a success or failure already occurred--and looking back and inventing the details why it happened--seems almost absurdly simple. Yet renowned scholars including Kahneman, Klein, and Karl Weick supply compelling logic and evidence that this approach generates better decisions, predictions, and plans.

--- Robert Sutton and Huggy Rao, in Scaling Up for Excellence

One of my favorite tools in business analysis is the premortem. Instead of waiting until the end of a project to find out what went wrong, and learn for the future, we can use this technique to go on an “imaginary time travel” to avert real failures.

A software project premortem works like this:

At the beginning of the project, block some time to imagine that it’s one month after the release of the software you are just starting to specify. Assume that the effort had the worst possible outcome. Write a story about why the failure occurred. It may look like this:

Rollout was a nightmare. By the second week after launch, there were more than 500 unresolved support tickets. The development team was overwhelmed trying to repair bugs and investigate performance issues. Transactions were delayed or timing out because the development team worked under the assumption that there would be no more than 10 concurrent transactions, when real-world use called for 100. Some of the features were so difficult to use, requiring jumping between multiple screens several times, that the training team had to create large documents to explain how to perform simple tasks. Users shifted to using spreadsheets to ensure they could do their job.

Do the same with the opposite result: pretend the project was a roaring success, and write the story that explains why.

Now, use the two stories to strengthen your requirements process. Typically, not all the potential pitfalls you’ll uncover in this exercise will be related to the BA work; ideally the exercise would involve the project manager and the entire delivery team. Doing this exercise in a group allows the team to “look back from the future” to describe the concrete success or failure of the project, and identify the roadblocks that need to be removed to ensure the successful version of the story prevails.

Still, even if it’s not possible to engage the whole team in a premortem exercise, and you have to do it alone, it’s a worthy step to ensure the quality of your requirements documentation. Looking at my example of the failure story, there is useful information to be extracted and applied to the requirements process:

• The requirements should specify the minimum quality the software must deliver, including performance goals relative to the expected number of concurrent users and transactions, acceptable mean time between data corruption and crashes, and so on.
• The requirements should include aspects of usability and learnability to ensure that users can easily learn how to use the system, and a dozen mouse clicks aren’t required to complete a single task.

Many BAs I have taught over the years have trouble identifying “non-functional requirements”--the criteria to evaluate the operation of the system that must be specified along with the system behavior to ensure the final solution is fit for purpose. One of the many benefits of doing project premortems is that it helps surface non-functional requirements that could become a problem if not addressed in the specification. These insights are available even from the description of the successful version of the future:

The launch of our new product was a huge success. Thousands of customers and prospects flocked to our website to sign up on the very first day. The feedback after a month using the product was overwhelmingly positive, and an average of 1,500 transactions a day indicated a high adoption rate. (...)

Looking at this “happy scenario” allows the BA to start thinking about capacity and scalability, and the potential need to build in excess load capacity as an insurance against crashes and delays that could alienate customers and make the business lose money.

Evidence suggests that looking at what could go wrong using the premortem technique to think in terms if “did this, not that”, rather than “do this, not that” give us a different, superior vantage point. It has definitely helped me succeed while working on complex and high-uncertainty projects. Have you used this technique in your projects? Can you see it making a difference in your business analysis practice? Do share your thoughts in the comment section.