When “Solutioners” are the Decision Makers

Have you thought about X? What about if Y happens? Are you sure that approach will solve Z?

These are all questions that business analysts should ask daily. However, one of the biggest challenges we face is when the decision maker for a project is a solutioner. While “solutioner” is a term one of my teammates recently coined, I feel that it is completely appropriate to define someone who has a desired solution already planned, and stated, before we’ve even had a chance to start analysis.

The IIBA defines business analysis as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.” This means that for a business analyst to truly conduct business analysis, we need to start with the problem or need, not the solution.

I’ve lost count of how many times I’ve been given an assignment, told what the solution is going to be (e.g. build a new application or product), and then told to do business analysis. How am I supposed to define needs and recommend solutions if you’ve already decided what we’re going to do? It’s frustrating to say the least. Understanding the real problem that needs solving and how stakeholders, processes, or products are impacted makes it much easier to find a solution that will actually solve that problem, rather than just putting a band-aid on the symptom.

Unfortunately, there is no one-size-fits-all approach for how to handle the problem of not understanding the problem. A lot depends on your relationships with the decision maker and other stakeholders or team members, your level of experience, the urgency of the initiative, and many other variables. However, there are some key Do’s and Don’ts that can help in your endeavor to get to the root of the issue:

1. DO develop relationships! I cannot stress this enough. The better relationships you have with key stakeholders and decision makers, the easier it is to convince them to let you do your job of analyzing the situation, rather than going straight into to developing the suggested solution. Having good relationships with decision makers also means you know what you’re getting into from the start. If I know going into a project which stakeholders are going to be pushing for a specific solution vs. those who are more open-minded, I can frame my initial questions and discussion points with that in mind in order to steer us down the path of problem solving rather than solutioning.
2. DON’T forget about the users who do the work. Quite often, the decision maker is not the actual end user of the application or product. This can mean that a decision to change a process or application can make things worse for the user who does the work every day. By understanding what the end user is doing, why they do it, and what their challenges are, it can be easier to explain to the decision maker why they may want to spend the effort to understand the true problem.
3. DO move forward with root cause analysis. It’s a BA’s job to conduct a root cause analysis and understand current state, so by moving forward with that analysis you are only doing what you’re supposed to do. Even if you have to spend extra time conducting analysis while also eliciting requirements, it will be worth it in the end because you will have a better understanding of the problems users face, even if the decision maker chooses what you feel to be a less than optimal solution.
4. DON’T be afraid to push back. If you are being pressured to document requirements or write user stories before you feel the proper level of analysis has been done, then don’t be afraid to say so. Obviously be respectful, but it is okay to say no if you feel it is the correct response. However, be prepared to back up your argument and try to provide estimates for the remainder of your work, if possible. As analysts, we should be comfortable with seeing all sides of an issue and understanding when to raise a flag when we see a problem. Which brings me to my last point:
5. DO bring the facts and ask! Explain to stakeholders what your role is as a business analyst, and how you can bring value to the project by understanding current problems and how they impact various roles or applications. Stakeholders or decision makers don’t always understand what a BA can do, so sometimes you can get what you need by simply explaining your process and how you can help. Tell them what you intend to do, when you intend to do it, and pledge to provide status updates as you go. By providing updates about what you’ve learned and giving alternative solutions to the problem, and you may just be able to persuade the solutioner to find a different solution, or even confirm that the original solution is still the best route to take.

Ultimately, convincing a solutioner to choose a different solution comes down to your relationship (or lack thereof) with that person and understanding how to use your instinct and expertise about the problem to know how far to push. Those are factors that get easier with more experience and longevity with your organization. But in the end, don’t be afraid to speak up and educate those decision makers in the value of analysis and understanding the true business needs; you just may be able to turn a “solutioner” into a “problem solver.”