Photo by James Peacock on Unsplash
Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations. In this article, Part III of the series, we discuss inversion. Parts I and II are about second order thinking and integrative thinking.
. . .
As described in the article Inversion and The Power of Avoiding Stupidity from Farnam Street, many hard problems are best solved when addressed backward. Inversion is a powerful mental model that shifts the focus from looking forward to what needs to be done to achieve a stated goal, to all the things that should be avoided in order for that goal to be achieved.
An easy way for business analysts to incorporate this mental model into their work is to adopt the habit of doing a Premortem at the beginning of each project. Ask yourself, “Imagine that this project turned out to be a complete failure. What would have happened to create this bad outcome?”
Armed with the answer to this question, you can then identify and recommend the countermeasures required to reduce the risk of the project failing to achieve the desired outcome.
Let’s look at a case study. A group of organizations initiated a project with the goal of retiring an expensive but flexible legacy system that supported a shared business process. Even though each organization was given representation in the meetings where project decisions were made, the project team ended up creating a solution that wasn’t customizable enough to accommodate some differences in the workflows of the partnering organizations. In order to eliminate the solution flaws, the project ended up taking twice the time and incurring a significant cost overrun. Even so, some of the organizations were forced to take the loss and start over with a separate solution in order to fulfill some of their unique requirements that turned out to be impossible to retrofit at a later stage of the project.
Years later, I was engaged to work in a similar effort involving multiple organizations. To prevent history from repeating itself, I used the inversion mental model to identify the potential pitfalls that would need to be addressed to mitigate the risk of project failure. Instead of simply setting out to understand the requirements of each partnering organization and documenting the differences in workflow that would require configurable settings (like done by the team of BAs who had worked in the previous project), I also did a premortem exercise that produced an output like this:
We’re now a year later. The project turned out to be a complete failure. Here’s what happened to have caused this bad outcome:
1. We rushed to the implementation phase after talking superficially with the partnering organizations, without performing a deep dive into their individual requirements and unique workflows. We realized too late that the feature set produced did not support all critical use cases. This caused a lot of rework, delays, and wasted resources.
2. We finally signed off on requirements that everybody agreed would fulfill all the needs of all partnering organizations, but without evaluating the potential impact on the business process of each individual organizations. During deployment we discovered that the new solution required some participating organizations to introduce new steps to their workflow that created unacceptable delays in the process or hire specialized staff they didn’t have the budget for.
3. The deployed solution was capable of supporting the internal processes of all of the partnering organizations, but the project failed to ensure that there was sufficient documentation and training material to enable administrators to adapt the system for each particular workflow. The only people capable of creating the proper configuration settings had already left the company, and the organizations had to renew the expensive contract for the legacy system while operations struggled to figure out how to properly configure the system for their particular needs.
The list went on, with more and more items being added by several team members looking at the problem from their various perspectives: business process, infrastructure, talent needs. For each point of failure identified through this exercise, the project team was able to establish a counter-strategy to prevent the problem. For instance, to avoid the issue described in item #3, a BA was put in charge of ensuring that proper documentation and training materials were produced throughout the project, with input from the vendor and a seasoned technical writer. The BA was also responsible for validating that the content of the training material was sufficient to enable the system administrators from each organization to perform the necessary configurations at the time of deployment. These countermeasures made it possible for each participant, at the end of the project, to efficiently and effectively customize the workflows and user roles & permissions required to support their specific goals.
* * *
There is incredible power in using inversion at the outset of a project to imagine ourselves in a future where the solution has not only been delivered, but is in the hands of end-users to get their job done. Rather than simply going through the typical project phases in forward motion, we can then look backward and gain additional perspective into what might go wrong so that preventive steps can be taken to avoid those bad outcomes.
One of the many reasons why inversion works so well to mitigate risks and improve the quality of project decisions is its ability to suppress a common cause of project failure: distance from the consequences. In a project that might take several months to complete, there is a significant time delay between an action and its consequences. Even when a team is using an agile process to incrementally deliver features that get tested every two weeks, it’s easy to overlook problems that are unlikely to become apparent until all the pieces are finished and the solution is ready to go to production.
While doing the inversion exercise won’t ensure that all potential project pitfalls are identified upfront, it can definitely help business analysts to develop a bird’s eye view of the initiative during its early stages. Because of the many expected benefits, including encouraging teams to avoid holding too tightly to ideas and concepts that might be based on false or unwarranted premises and shortening the distance between actions and consequences, this mental model is one of the most powerful tools BAs can use to improve their results and elevate their role.
Author: Adriana Beal, Lead Data Scientist at Social Solutions
Since 2004, Adriana Beal has been helping Fortune 100 companies, innovation companies, and startups in the U.S. gain business insight from their data, make better decisions, and build better software that solves the right problem. In 2016 she decided to follow her passion for quantitative analysis and got a certificate in Big Data and Data Analytics from UT. Since then she has been working in data science projects related to healthcare, IoT, and mobility. Currently the Lead Data Scientist at Social Solutions, Adriana has two IT strategy books published in her native country, Brazil, and work internationally published by IEEE and IGI Global. You can find more of her useful advice for business analysts at bealprojects.com.