Importance of being Business Analyst

I have worked as Business Analyst (BA) for various assignments, most of which required frequent face to face client interactions. There is a flurry of articles on the internet describing the importance of BAs. The few articles I have gone through do not touch upon some important practical aspects of the role. No matter how good you are in understanding customer’s business, failures are inevitable if the practical issues are not addressed properly.
As this is my first article on Business Analysis, I will get by and large stick to few commonly known but poorly practiced activities.
Let’s start with Stakeholder agreement.
In most medium and large organizations, all the stakeholders are not on the same page concerning the final software they want to see. It is simply because each of the client stakeholders thinks differently.

• A user will most likely look at the ease of using the software.
• Few other users would worry about their job going away because of the automation, and they would want to see more and more user intervention in the software.
• An IT Director/Lead, who is the technical sponsor, will look at keeping costs down and giving one running version of the software as soon as possible. Their agenda would be to minimize schedule overrun and cost overrun. Many times the IT Sponsors want to utilize the budget available at their disposal, even if it is not spent efficiently. That is because the variance in the budgeted and actual amount spent is not seen in a good light. Who knows the IT project being pursued is because of the need to utilize the available funds.
• A business sponsor, who is investing in the idea of the software, will try to maximize the ROI at the least TCO. Such sponsors care about the bigger picture keeping at bay, the finer details which later become a problem if BA is not capable enough.

All in all, a BA needs to find a right fit between the expectations of users, technical sponsors, and business sponsors. The allegiance of a BA should lie with Business Sponsors, IT sponsors and Users in that order.
Depending on organizational politics, a BA might not have much say in few matters and may have to document the conflicting inputs and highlight the anomalies for the stakeholders to agree.

Next in line is requirements sign-off.
Which company would start a project without getting a sign-off on the requirements? There wouldn’t be many. So, why are we even talking about this?
I have worked with Managers who think that sending the completed requirements document is sufficient to work on their side. They believe once the requirements document is out for sign-off, it is entirely customer’s responsibility to give a sign-off. In most cases that doesn’t help the project.
Remember that within the customer organization people who understand business aren’t the people who understand technology also. Vice versa may not be true, but that doesn’t matter because typically the users, business sponsors are the ones to give a sign-off on Requirements Document. Any Business Analyst also tends to use some technical language in the requirements document, which saves him/her the effort of making the developers understand. This doesn’t go very well with the business sponsors as they don’t understand technology very well.
Business sponsors skim through the elaborate requirements document, find some information which they have already given the requirements and provide a sign-off. But during further detailing and actual implementation new scenarios come up which are unaddressed. A fault of the BA, right?
Even if we get a sign-off from a customer, it is essential to get a sign-off in intention and full spirit from the stakeholders by making them understand the requirements as they are captured. Hence, a BA should proactively make the users, business sponsors, technical sponsors replay what is captured and how it is recorded in the requirements document. In most cases users understand better if we play clickable mock-ups of the software, using software like #axure, etc.
These activities establish the client’s trust with the software vendor, and you as a Business Analyst play a pivotal role.
The same principles hold for Agile development also. Just because the development methodology is agile, it doesn’t give the right to users, business sponsors to change the requirements often. More often than not, all these projects run under tight scope and cost schedules. A significant change in scope is a loss of time, energy and money.
Finally, let’s talk about the relationship with Development Team. Ultimately, they are going to develop the software/product.
Many good tech geeks take absolute pride in the knowledge they possess. They tend to question and at times challenge the BA on many aspects of decision about the software. A Business Analyst needs to have the behavioral skills by which the energy and technical soundness of the developers are channelized well. A Business Analyst needs to keep himself calm, composed and should hear out the options given by developers and treat each suggestion on its merit. Questioning the developers to understand more about the possibilities is a good practice, but questioning by casting doubt on the developer’s ability is what makes the developers hate you. Such BAs are destined to fail.
Do send me any questions which you may have.
Happy BAing :)
Get more insights on YASH : Data Science & Analytics services
Pallav Maheshwari- Manager – Strategic Initiatives @YASH Technologies

• BA
• Business Analysis
• Business Analyst