I’ve encountered this question many times. What does a business analyst do? From basically everyone — my family, friends and different members of the IT community who haven’t worked with Business Analysts yet.
Even though I’ve tried to explain to them what I do, in a few months, they would come back to me with the same question: “But…what do you actually do?”
Business analyst job description
During recent months I have found some time to think about what do we (BAs) do, and I came to the conclusion that each BA has his own idea of what he does. This happens because the field of work for BAs is quite broad and can vary a lot from one project to another. Also, BAs have different knowledge that they want to make the best use of whenever possible.
What I “think I do” is filtering requirements. This is how it looks like:
This is where the BA brings the most value to the project. The final results should be clear, unambiguous requirements, prioritized and organized well for each team member to understand them almost at first sight.
Many BAs will tell you that we are the problem solvers, the bridge between the customer and development team, etc.
Yes, that is true. I like to point out that filtering requirements is the key point because if not done correctly, the BAs have more problems to solve, more time to spend on “bridging” and more meetings to make.
What do I mean by “filtering” requirements:
- gathering requirements which will solve the right problem for the customer (sometimes it implies digging deep to find them). One of the best ways to do that is to focus on the goal of each requirement, not just on what the clients want;
- building an optimal requirement structure (documentation) in order to make it easier to understand for all team members — to improve planning, and to avoid blockers in the development phase;
- prioritizing the requirements well, in order to increase the utilization of project resources.
Business analyst skills
In order to collect the “right” requirements, a BA must ask a lot of questions. Let’s put this under communication skills.
This is one of the toughest challenges for new BAs who want to do a good job because it is necessary to get over the idea that you might look silly or stupid. How you look and what clients think at this point doesn’t really matter (a lot😊). What really matters is that you’ve achieved what’s best for the project and you’re certain that clients will be pleased with the outcomes they see.
Furthermore, to build an optimal requirements structure, a BA must have some documenting skills. Requirements must be grouped well, unnecessary information must be avoided and the language used must be clear and precise. The simpler the documentation appears, the more experienced the business analyst behind it is likely to be.
The final point to discuss about is prioritization. In my view, nobody on the project should follow the idea that the first task should be changing the color of unimportant text in the application’s interface just because they prefer blue over red — rather than addressing a critical bug. Let’s make it clear, the way the application appears to customers is as important as the appearance of any other product. But on the other hand, some things are just not that important and it’s the BA’s job to be aware of it.
Don’t get me wrong, there are many other necessary skills for a BA to develop in order to do a good job and bring more value to the project. These are some of the important ones if you wish to make the “filtering” process work. Sometimes there is a fire waiting to be extinguished and new skills waiting to be shaped.
A Few months later in a coffee shop nearby
Friend: “Ok, but what do you actually do…?”
Me: “I filter the requirements in order to make applications for the clients”.