Decision-Making Compass: A Powerful Lever for Business Analysts
During the progress of any complex project, change is inevitable. It’s the failure to make optimal decisions to manage these changes that leads to substantial risks.
Consider this real-life example:
A company was implementing a new user portal for customers to order services and pay for them. While working on a cancellation feature, the development team identified a requirement gap. What should happen if a paid order is canceled? Should the system issue a refund, returning the money to the payment method originally used? Provide store credit for use in future purchases? Allow the customer to choose between these two options?
As the need for a decision was communicated, a contractor pointed out that implementing the ability to credit the customers to their original form of payment would require an expensive integration. Armed with this information, the project sponsor decided to only support store credit in the case of cancellation.
After the new system went live, though, the company was flooded with bad customer reviews posted by angry customers who had paid for the service only to be told it wasn’t available at their location. Not only were they denied a service they wanted because they couldn’t schedule it at their address, these customers were left without any means to recover their money or use their store credit. To contain the backlash, the business ended up spending twice the original amount to incorporate the refund option to the solution.
Ideally, we’d avoid this kind of negative outcome by laying the proper foundation during requirements analysis to ensure the business need was well understood. Of course, expectation and reality are not always in alignment. It’s not uncommon for complex projects to require last-minute decisions to be made to address unforeseen (or even unforeseeable) circumstances.
But that doesn’t mean we should resign ourselves to filling requirement gaps with hasty choices that risk busting budgets and schedules and threaten the project’s long-term success.
How to Apply a Decision-Making Compass to Critical Project Decisions
To illustrate how a decision-making compass can improve the quality of a complex decision, let’s run our example through the steps I use in most of my own projects.
(Keep in mind that the exact frame you adopt is less important than having a template that helps decision-makers acquire a more structured understanding of the decisions to be made, and the uncertainties surrounding them. This is just one example of methodology that can be modified depending on your situation.)
1. Define the problem
Successful problem solvers know that nothing is more important for finding a superior solution than the rigor with which we define the problem. Unfortunately, a common reaction is to rush to resolve the issue without properly articulating the challenge, which often leads to erratic decisions.
To quote from the article Avoiding Bad Decisions in the FS blog,
The first person to state the problem rarely has the best insight into the problem. Once a problem is thrown out on the table, however, our type-A problem-solving nature kicks in and forgets to first ask if we’re solving the right problem.
The solution? Never let anyone define the problem for you. In our user portal example, the sponsor was approached by a contractor who framed the problem as scope creep that would increase costs and introduce complexity in the solution. As a result, he started thinking about the problem in a narrow way, and through the wrong lenses.
2. Identify the criteria for the decision and corresponding weights
Most decisions require you to accomplish more than one objective. Making a choice without a clear set of relevant criteria increases the risk of a choice that places too much importance on one aspect of the solution and fails to recognize other relevant factors.
In our example, the relevant criteria for project decisions included project cost, time-to-market, and customer satisfaction. When rushed for a decision, the project sponsor focused exclusively on the first two factors, neglecting the third, with damaging consequences for the business.
Since decision criteria may vary in importance based on the project, business goals, and other considerations, each factor may need to be given a weight to assign it a lighter, or heavier, importance in the decision.
3. Generate alternatives
When considering project choices, rather than thinking of the available options in isolation, the best approach is to involve the various stakeholder groups that can contribute with their business and technical expertise.
The more diverse the group of stakeholders consulted, the richer the solution space becomes.
Including other groups would have helped remove the blind spot experienced by the project sponsor in the user portal project:
As the team most familiar with customer behavior, the customer support team might have been able to point out the negative impact for customer satisfaction of exclusively offering store credit in case of a cancellation.
As the team most knowledgeable about the revenue cycle, the finance team might have suggested waiting to charge the customer after the service availability had been confirmed and the “regret window” had closed. This solution would eliminate the need to develop the costly refund feature since by definition all cancellations would happen before any payment took place.
4. Rate each alternative on each criterion and compute the optimal decision.
In this step, we set to answer the question: How well do each of our options meet each of the defined criterion?
To compute the optimal decision, ideally you’ll be able to multiply the ratings by the weight of each criterion, and add up the weighted ratings to find the alternative with the highest sum of weighted ratings.
Breaking Down the Barriers to Adoption
Stakeholders may resist the adoption of a decision-making compass for a variety of reasons:
Change can be uncomfortable, disruptive, and uncertain.
Going through all the steps in a decision process every time a project requires a consequential decision could slow progress down.
If your process relies on stakeholders to define criteria and assign scores and weights to them, there is the risk of introducing a high degree of subjectivity or bias in the assessment.
But it should be easy to point to the paradox here. Overall, the risks of a bad decision affecting project timeline and outcomes will be minimized if stakeholders agree to apply a more systematic process to understand the problem and compare alternative solutions.
It’s true that suggesting the idea of a decision-making compass in the middle of a project, under the pressure to deliver, is likely to be met with strong resistance. This is why it’s best to make the suggestion during a post-mortem meeting.
At the end of a project that experienced significant rework, delays, or wasted resources, it shouldn’t be difficult to find examples of poor choices based on shortsightedness that contributed to the negative outcomes. This can open the perfect opportunity for the BA to recommend the adoption of a decision reference frame to help prevent such issues.
Conclusion
In complex environments, cognitive load (relating to tax complexity and multiple inputs that affect decision-making) can significantly hamper the quality and efficiency of project choices. High-performance business analysts can play an integral and important role to avoid this issue by advocating for the adoption of a decision-making compass to deliver insight to stakeholders about how well their objectives may be satisfied by potential alternative courses of action.
The next time you’re embarking on a high-stakes project, make sure you have a decision-making compass ready to use, even if only informally defined. While there is no guarantee that applying it to project choices will completely eliminate the risk of mistakes, it will no doubt help move things in the right direction and maximize performance.
Author: Adriana Beal
Adriana Beal spent the past two decades helping innovation companies leverage decision science and machine learning to improve business outcomes. She recently left her job as a principal data scientist with a global AI consulting group to return to her roots as an independent consultant. You can find out more about her work visiting bealproject.com.
 | A guest post by
|
Nothing to disagree with in this article, but it does rehash age-old concepts that those of us "of a certain age" would recognise as: Full Requirements Elicitation and Analysis, Stakeholder Map, and Communications Plan, with a nod toward Risk Analysis. These factors should have headed off this eventuality and prevented this adverse situation from happening.
Done properly Options for Change within the project would have been presented to all stakeholders, your diagram in section 4. However, what is missing from that diagram are the risk categories that must include the business reputational risk, which this article encounters. Obviously, the project's cost risk is a factor, but is of less importance than the BAU risks encountered. The Project Sponsor, in my opinion, is the least qualified to make this sort of a decision. They are looking short-term at project delivery and cost management, with a view to moving onto the next "shiny thing". Yes, they have decision-making capabilities, but of a limited nature. Big decisions like this are not theirs to make.
So, actually, there are more issues illuminated in this example than the simple wrong decision made. There is a Project Governance problem to address.