What is a Business Analyst? – One of the most googled question about BAs

When I was conducting extensive study on this fantastic mediator analogy, “The Business Analyst,” I recall having this common and nagging question in the back of my mind👇🏻

“What are these group of people, to whom we are referring as Business Analysts”?

And, yes, now I can understand the pain of others who are riding on this same bridge.

Guys, come on, this is a valid question because we know that in the corporate world we have people who have a job title, but their job role is something different and, while working on a project, what they are actually doing might be entirely out of the box.

Finding the unique characteristics of BAs in this group of so-called “Analysts” is an enormous workout.

Relax, I’ve got this.

If we go back a little and try to remember what was going on just before the IT boom, we can see that there were “so-called back-end personnel” mechanically processing mountains of paper.

A lot of data brought a lot of scope for automation, and hence the demand of software development.

Now just imagine, a business geek, coming to a full stack developer, telling him to make software to increase business revenue. The developer doesn’t know how to code this because he doesn’t know anything about business revenue.

This brings the IT industry to need someone who is sound with business terms and knows how to tackle them, but also understands the technology needed to handle “development” stuff. This role is now called a “Business Analyst”.

A Business Analyst might be thought of as a translator (much like a tourist translator, hehe).

A business analyst is a translator who sits with stakeholders to understand what their business requirements are, what they are looking for, what their goals are, why they want a certain solution, etc., who can then move onto the tech team to help them understand what they need to build out of those requirements, so that the business is given a tangible solution that meets their requirements.

So if you fill in the section “languages known” in your CV to be “Hindi & English”, then you better sit at home; because what the interviewer really wants to see is “Business and Technical” (lol…just kidding).

Even though a BA understand business requirements, this doesn’t mean they can simply nod and go ahead. There has to be proper documentation of each and every discussion that happens between business stakeholders and a BA (sitting along with a project manager and other team members too).

Some of the tasks might include writing these requirements in BRD or FRD, creating some flow charts for easier comprehension, and practising brainstorming, mind mapping, and several other techniques. Since we have a BA to handle all of these now, stakeholders are set free of such burdens. (documentation is the 2nd topmost skill of a BA, with communication remaining 1st).

A BA role will vary with each organization, from projects to be worked on to last minute requests (e.g. the project manager is not available, then a BA has to jump in and lead a meeting with stakeholders).

In addition to this, some fundamental requirements which could help clarify who these folks are include:

• Someone who plans a proper requirement gathering session as per stakeholder’s availability (which may get rescheduled several times).
• Someone who doesn’t take all the requirements blindly, coming from a stakeholder, as they are very well aware that a developer is sitting next door. (I will cover this scenario on how to answer stakeholders if they are asking for a lot of stuff to be built)
• Someone who works on a proper roadmap (thanks to PM who “sometimes” sits with a BA for this) and discuss with his/her tech team on story points and sprints (as they will be building the stuff, not a BA)
• After this, if anything goes out of the way, then he/she will immediately call a meeting with stakeholders and explain to them why this is happening (again, this may be rescheduled several times)
• Someone who keeps everyone updated on progress of the project, or else stakeholders will chase them for weekly status reports
• Very importantly, someone who tries to take all major requirements beforehand (during elicitation) or else stakeholders will again chase for change requests when development team would be working on the final sprints of the project
• Someone who is OK with being a bouncing ball between the development team and stakeholders to work things out in a proper way and make sure nobody gets hurt/anxious/etc

These are just some of the practical things a BA is going to experience during his/her role. Whether it’s a Big4, MNC or any startup, these are the everyday essentials which actually defines them.

I’m hoping that this has helped you to understand a difficult subject that constantly remains in your thoughts.

Watch this space for more similar thought-provoking real-world experiences from my travels where I go deeper into the subject of business analysis.

Follow Bhavini Sapra and subscribe to get updates on my posts.

Connect with me on topmate.io/bhavinisapra for anything and everything you are perplexed about Business Analysts.

Hi-Fi!!