So, you are a business analyst and you are given a problem to solve. Business stakeholders explain the problem to you and you set about identifying requirements for solving it… Sounds easy?
If it was that easy, what would analysts do all day? In reality, you cannot assume that the problem as it was described to you is the real issue. It may be a symptom of a more complex problem or a pain point that has multiple causes. Before you forge ahead to solve a problem set in front of you, make sure you understand what it is and what it is not. Discovering the real issue may turn out to be the hardest task you will undertake.
Here is a real-life story for you.
An operations business unit has been recently divided into two in an attempt to streamline the division of work. Previously, the work was assigned to specialists based on the type of request and their area of expertise. The management felt that it was not very efficient: the requests did not come in a steady flow, so some specialists would be behind while others had nothing to do. The reorganization created two teams, one to service large clients, and the other for small clients. Specialists were divided up between the teams, the large client team getting the majority of more experienced workers since bigger clients often had more complex requests.
A business analyst was called to task when the realization came that there was no clear method to dividing tasks between the two teams. The work still came in through one pipeline, so one person that knew all clients well was assigned to manually split up the work between teams each morning. The determination of large vs small clients was a bit subjective and that started to cause tension. And of course, when this person was away, someone else had to pick up the triaging.
Hastily, sales history data was requested from the business intelligence team in an attempt to come up with quantitative criteria for large vs. small clients. A business analyst was requested to put together requirements for collecting historical data and building some analytics to help classify clients as large or small. The business analyst spent a few days mapping the existing process that the two new teams followed, then a few more days studying the data on sales volumes. The requirements started to take shape but never seemed to be done. The stakeholders kept arguing about the criteria.
In the end, the analyst realized that the data collected in the data warehouse was not sufficient to determine client size reliably. If a client only placed one order, it was too early to tell whether the client would be big or small. There was no information stored about the size of the client’s business or revenue. And when a new order from a brand-new client came in, the client profile was not in the system yet, so routing to one of the teams might as well be random.
The business change was clearly not working, since no clear rules about dividing up the work could be agreed upon. After much time spent in meetings, frustrated team leads started to meet each morning and divide up the work for their teams manually. Any efficiencies that might have been gained were eaten up by delays in assigning work, redirecting tasks between teams and arguing about who should own which client.
From a business analyst’s perspective, no amount of sales analytics was helping. The specific reporting requirements that the stakeholder requested were not going to solve the real business problem.
So, what was the real business problem, even before the teams were split up?
The pain point was that work assignments were distributed unevenly, causing a backlog of cases and unpredictable workloads. But if we ask “why” a few times, we would discover the underlying problem: the number of workers that specialized in specific services was not proportionate to the actual volume of services requested.
Do you want to know the outcome?
Through much pain and with the help of the business analyst, the stakeholders realized the real problem, which was narrow specialization and lack of knowledge. In the end, they agreed that cross-training employees is a smarter solution than trying to predict volumes of work to right-size the teams.
The teams were merged back into one. Each team member was trained to handle multiple transactions, and the work was divided on a first-come-first-serve basis, with each team member monitored for their daily productivity.
Lessons learned for a business analyst?
- Remember that you cannot solve the problem until you are clear about what it is.
- Make sure you separate causes from symptoms, and correlation from causation.
- Do not assume what the cause of the problem is – investigate and analyze it.
- Do not take problems described by your clients at face value – expect that there will always be more depth to the initial problem than what was handed to you.
- If you realize that you have been given a scope that already assumes a solution, and your analysis shows that it will not solve the real problem – speak up. This is exactly when you need your business analyst mindset.
- If you are apprehensive about challenging someone else’s decision, think about all the resources that the company will be spending on implementing a solution that would not solve the real problem.
It is part of your professional integrity to help the business spend money and resources on solving the right problems.
Want to succeed in business analysis? Apply the twelve principles of the business analyst mindset. Sign up for the Why Change newsletter for more resources and to receive your free copy of the BA mindset poster.
Explore the #ba_mindset in other formats: books, videos, or courses. Or contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
14 comments