Years ago, I was consulting as a Principal Business Analyst for the second largest company in the world in the money transfer business. One fine morning, I was engrossed in my work when my business stakeholder, (let's call him Tom) arrived at my desk.
Tom: Praveen, I have a change request for you. Well, this is a new business requirement.
Me: Oh...a new business requirement! Okay. Sure..let's hear it.
Tom: You know the search screen that we have (see below). I want to change it.
Me: Okay...
Tom: Essentially, I want you to remove all the search criteria fields, and replace them with just two fields...one, a drop down and the other a text field. The drop down will have the same values as the current search criteria. The Agent (i.e. the User) should first select the search criterion from the drop down, and then enter the search value in the text field.
Me: So, the new screen should look like this, ha?
Tom: Exactly!
Now, here is a question for you. Pause reading this article for a minute and ponder over what you would do at this point if you were me. Here are some options:
- Update the Search Transaction use case to reflect the change and pass it over to the design team for implementation
- Ask Tom to meet the PM and follow the change control process
- This seems like such a simple change...there is no change to the actual search function, just some UI modification...so circumvent the change control process and just get it done
- Perform a detailed impact analysis and figure out all other functionality that might be impacted because of this change.
- None of the above
What would you do? Which option would you opt for?
Sounds like option 4 would be the most logical path to take.
However, if you chose option 5, you would be right. I didn't choose any of options 1 thru 4 either.
What I did was to ask the most important question that a BA must ask -WHY.
Me: Tom, this is a simple change no doubt. If you could humor me for a couple of minutes, I would really like to know why you need this change? What is happening in the business that triggered you to bring this change request?
Tom: Here is the issue Praveen. You see, when a customer intends to make a money transfer transaction, she first logs on to our website. She then creates a Send Transaction where she enters all the details, i.e. the sender details, the receiver details, the amount of money to be transferred, etc. Once she enters all these details, she saves the transaction.
Me: Okay...got it!
Tom: Then, she takes the actual cash and heads to one of our Agent location. The Agent has access to a money transfer terminal. The Agent asks for her name to pull up the saved transaction on his terminal. The customer states her first name. Now the Agent types in her name in the Last Name field. The transaction is not found. The Agent asks her name again, makes a mistake...and can't find the transaction. The customer is irritated, and she goes out straight to our competitor.
Me: Oh vow!
Tom: That is why I want this change. I want to make sure that the Agent actually asks the customer whether she is stating is her first name, last name or something else. That is why the drop down field. I want to make sure that the Agent is able to pull up the transaction in the first attempt.
Now, my dear reader...think about this real business problem and then look at the "business requirement" that Tom has brought to me. What can you observe?
Did you get it? Exactly...you got it!
One, Tom has actually brought you his perceived solution and has disguised it as a business requirement.
Two, the solution that Tom has brought will definitely NOT solve his business problem. How can having a drop down box eliminate the possibility of making mistakes on the search screen?
Having now understood the real business problem, you can think of several possible solutions:
- When the customer saves the transaction, let's create a unique ID. Instead of searching for the transaction using name or other criteria, searching using the unique ID is much more robust
- Create an intelligent search function, where there is no need for any search criteria label...enter anything - name, SSN or anything else. Make the search function so robust that it searches all saved transactions and pulls up all transactions closely matching the search value and displays the search results sorted by relevance
- Etc...etc...
Think about what would have happened had I not asked that 'WHY' question! I would have ended up implementing what Tom wants, and not what Tom needs. After the new search function is released to production, Tom would have very soon realized that the solution is not working at all and his problem still persists. Who Tom would blame then is anybody's guess.
By the way, in my 15+ year career as a BA, I have noticed several BAs not asking this WHY question. This is why I suspect these BAs become infamous in their team as "just postmen" who add no real value to the project.
I cannot really overemphasize the importance of asking WHY for a BA. A good BA will always understand the true underlying business problem and solve that problem. A good BA will never take any statement from a stakeholder at face value and treat it as a requirement. Remember the 'A' of BA!
P.S. It would be interesting for you to learn that solution #1 above could not be implemented because a competing organization had patented that process! The patent prevented my client from creating any identifier that uniquely identified the transaction. My client therefore had to use one or more pre-existing identifiers to identify the transaction.