I was reading a comic strip the other day that I found very witty, and yet pretty apt. Two business analysts are talking to each other and they are discussing their plan of action to document the project requirements.
Business Analyst 1 asks:”So how do we plan to gather and make use of the requirements?”
Business Analyst 2 replies:”Well! Let’s just gather all the information we can. We will think of the usage later!”
I could not control my laughter after reading it because this is exactly what happened during one of my recent client engagements. I was working with a couple of business analysts, trying to understand and finalize the requirements. Once we were done with the requirement gathering workshops, I asked the business analysts to share the requirements.
The business analysts came back with an enormous word document and piles of spreadsheets that contained thousands of rows and columns with different Yes/No/Maybe statuses, multiple colour legends, excel formulas and what not! Okay, Okay, I know I am being a tad overdramatic over here but I am sure you get the point.
Making sense out of this heap of data was a very time-consuming and a pretty cumbersome task. In the end, I figured out that most of the data gathering exercise conducted was literally of no use to us. It could have been smartly dealt with. The business analysts should have been more selective in gathering the data. But what can be the reason behind it? Why do we come across this case of “too much data”?
Blame it on the human nature!
Let’s take an example of a TV show, a nail-biting suspense thriller. The show is bound to get over as a cliff-hanger today. You, as an audience, will be teased to come back tomorrow, same time, to check out what happens next! You know why? It’s because we tend to get restless, if we sense uncertainty. Human mind needs to have an answer to all the queries.
We often like to think that the more information we have, the better off we will be in terms of making decisions. When data or information is missing, we tend to attach undue importance to the missing data. A warning bell rings in our mind, “Note it down. This is important!” You see, that’s the trap. Our mind starts focusing on the nitty-gritty of “what’s missing” rather than focusing on the “bigger picture”.
If a business analyst gets trapped into this mindset of data-curiosity, they are inevitably digging a deeper hole for not only themselves but also for the entire project team. One needs to be smart enough to remain astray of the missing-data obsession. Requirements will never be complete. Some questions will always remain unanswered.
A smart business analyst will often tend to make intuitive assumptions for the missing information. They will always ask this question –“Is this really worth exploring? What is the business value out of it”? If you don’t have an answer in affirmative, well, just move on. There is no point spending any more time on this missing information.
Scope Clarity
While having discussions with the business, a business analyst may face issues related to scope finalization. Due to a lack of clear scope definition, requirements may get vaguely understood. When you have vague requirements, you are bound to create poor business requirement documents. Like they say –“Garbage in is Garbage Out!”
If the requirements are not clear, you are bound to waste your time in getting in touch with different stakeholders, trying to get answers to the questions, about which you are not clear yourself. Again, a case of capturing too much data! To avoid such issues, the business analyst must work in tandem with the project manager to ensure that the project scope is defined and it is in sync with the TO BE solution to address the business needs.
Donning the technical hat
As with the case of vague scope definition, the same logic applies to the technical side of things as well. As a business analyst, you are not required to be a tech-guru who needs to understand each and everything related to the technical aspects of the project. But you do need to understand the bigger picture – in terms of how different IT systems talk to each other, what are the technical touch points in the business process flows etc.
If you are unsure about how IT fits into the scheme of the things, with respect to the business and the project, then you will start going from pillar to post, seeking answers to questions which are inconsequential. You may also run the risk of rubbing people the wrong way by asking too many questions. And, if you notice, you have again fallen into the vicious circle of capturing excess data.
Conclusion
Never forget the thumb rule – Requirements will never be complete. As a business analyst, you should know when to call it quits. You need to make smart assumptions at times. Avoid getting trapped into analysis paralysis.
Secondly, you should get the business scope defined in a clear and concise manner. A clearly defined scope will lead to the creation of a neatly drafted business requirement document.
And finally, aim at understanding the entire business process flow, keeping the technical touch points in mind. Utilize the project documents such as Process Flow designs, Solution designs etc. to understand the business processes. Juggle your technical and business hats smartly.