Business analysts (BAs) help companies develop, improve, and optimize their processes. But is it always advisable to involve a BA in a project, let alone have one on the team? Anton Rotachov, Business Analyst and Product Owner Senior at Levi9 explains when a company needs a business analyst and when it can do without one.
Before drawing conclusions about the feasibility of BA in a company, it is worthwhile to determine why a business analyst is needed in the first place. The image below briefly and clearly answers both questions, so you don’t need to go any further. However, I want to go into more detail, so get ready for the long read. I will describe the processes in the example of business analysis in IT, but in general, the principles of business analyst work are the same in any field.
A business analyst strengthens the company
We live in a time of the industrial and technological revolution. The world around us is changing quite rapidly, and the competition can throw the history of companies with outdated and inefficient business processes into the trash. The development of technology dictates new realities: we either adapt and use it to our advantage, or we stay on the sidelines.
Companies need to constantly evolve, face challenges and develop new efficient business processes. They will be complex, branched, and involve many stakeholders, each of whom will look after their own interests based on their own requirements, assumptions, and reservations. In such circumstances, how do you bring everything together, identify what is necessary, align the expectations of all parties, and finally launch the task into development? How to build the most transparent, efficient and understandable business process? To do this, a company cannot do without a business analyst.
What do business analysts do, and what is their superpower?
Collecting product requirements
A business analyst must collect and document the requirements of all stakeholders. He or she is engaged in so-called stakeholder management, which increases or decreases the proportion of certain requirements. For example, in the case of accounting software development, the accounting department will be the key stakeholder whose requirements will be given the highest priority.
The wishes of secondary stakeholders, such as HR, who would like to send personalized payroll statements to specialists, will be less important. Of course, they need to be taken into account, but the business analyst must understand who to hear and who to listen to. BA gathers information from stakeholders in all possible ways: at meetings, interviews, clarification in chats and messengers, studying documentation and other available sources. It is during the collection and formalization of requirements that a business analyst must demonstrate his or her superpower, which is the ability to listen and analyze what is being said. BAs should immerse themselves in the customer’s problem, feel their pain, listen to their vision of the solution and offer their ideas. If necessary, they should also analyze the market and customer needs.
To process incoming data, it is useful for a business analyst to understand the domain or industry in which they work: expertise and experience will allow them to find and implement effective solutions faster. At the same time, there’s no need to be a subject matter expert: a professional business analyst won’t be hampered by knowledge gaps, especially since they can always be filled in.
Requirements approval
After researching the problem, and collecting wishes and visions of the future project, functionality, or solution, the next step for BAs is to approve the requirements. To do this, all the information collected needs to be structured, analyzed and compared, and then brought to a unified, understandable form. The result should be refined and valid requirements in the form of a document called a BRD (business requirements document) or a task on a project management platform.
The requirements for the future solution should clearly and concisely describe the problem and ways to solve it, have no logical discrepancies, and be agreed upon with all participants in the process. In the case of a commercial product, it all comes down to the profitability of the functionality being created – the ratio of resources spent on development to the expected profit. At the same time, the requirements should include not only target values but also product metrics, such as approaches to tracking and measuring them, indicators of development success, etc.
Development, implementation, and monitoring of results
Next, the solution is developed, large tasks are decomposed into smaller ones, and regular meetings are held to clarify and discuss implementation details, both technical and business. Here, BA acts as a link between the business’s wishes and the technical implementation of the development, advising both parties and making sure that the customer eventually receives the product they need.
The final stage of the cycle is the implementation of the developed product, for which it all started. Customers use the product first in test mode and then in commercial operation, scaling the solution if it is successful. The business analyst remains a kind of guiding light along the way: he demonstrates intermediate results to all parties, validates changes, and collects feedback from users and all those involved to improve and develop the implemented solution in the future.
So, does a company need a BA?
The description of the path from an idea to a finished solution or product makes it clear what layer of work BA performs at different stages of a project. If the company doesn’t have a business analyst, his or her responsibilities are delegated to someone from the team or stakeholders.
Can the company implement new effective solutions or improve operational processes without a business analyst? If it’s a large multi-stage project involving various beneficiaries, then obviously not. Distributing BA responsibilities among project participants is not the best solution, as it only leads to a blurring of functions and areas of responsibility and increases the likelihood that something will go wrong.
So, to summarize: a business analyst on a project is important. And if the project has a branched structure, many stakeholders, and unknown variables that need to be constantly validated and worked out, if it is necessary to keep teams in the same information field and quickly adapt the product to changes, then a business analyst is a must.
