Creating a project without a BA is like being a taxi driver... in the pre-Uber era and without GPS or internet. Now welcome your passenger, a foreign tourist, trying to explain to you (without Google Translate, remember?) where they need to get urgently.
You surely are a very experienced, first-class driver and know the area well. And your passenger, in turn, clearly knows the location they want to go to. But will it help in this case? Will it help you save time or fuel, choose the most efficient route on the first try, and finally, complete the trip without undue stress and nagging hassles for you both?
As pretentious as it may sound, it is true, and here we explain why.
For this article, we talked to Yuliia Hlushko, Lead BA at Binariks, who helped us clarify the role of business analysts in IT and our company approach to business analysis in particular. Without abstract descriptions and vague words, straightforward and to the point, just facts and examples.
Reconsidering common myths and cliches about business analysis
The role of a business analyst in an IT company is shrouded in stereotypes, migrating from one article on the subject to another. Some of them are damaging myths needed to be debunked, while others are just cliches, true in theory but overused to the point of losing their sense.
So, to clarify the picture, we gathered – and commented, complemented, or just put paid to – the most common perceptions regarding business analysts. Let's go!
Cliche 1: Business analysts are just requirements gatherers
FALSE
Though there's nothing wrong (as well as easy, by the way) with being a "requirements gatherer" or a technical writer, the role of a business analyst most often extends far beyond these responsibilities.
Just as with other roles in IT companies, its emergence was due to necessity. More precisely, it was the result of the complication and sophistication of software solutions. Roughly speaking, an evolutionary timeline of the business analyst role emergence looks something like this:
Thus, a BA is the one who makes sure that the team understands the client's ideas and can address the solution correctly, the one who can offer something the client truly needs to reach their goals, not just what they want.
To sum it up, business analysts are multitaskers. From technical writing and requirements management to MVP features defining, building a product roadmap, benchmarking and market analysis, and other processes related to product ownership, product management, etc., business analysis focus and tasks to be performed can vary depending on the project.
Yuliia Hlushko says: "Not every analyst covers the whole range of these things, and not every project needs this. We call all of this business analysis, but our analyst can focus on any areas required in specific circumstances, for a specific product and a specific client. In some cases, it may really be enough to write down the requirements, but that's the exception rather than the rule."
Cliche 2: Business analysts will evaluate your business idea
FALSE
Though the term "business analysis" really contains the words "business" and "analysis," it's not about analyzing the way the client does their business but analyzing the best available options to achieve the client's business goals.
Similarly, it is not about evaluating the client's business idea, which is also a common confusion among people seeking a way to create a software solution without involving a BA. They may think it is unnecessary if they've already come up with a great and valuable idea and are confident in its potential.
In reality, a BA is by no means changing or "reshaping" the client's business goal, but sometimes helps to define them clearly and is doing their best to help the client to achieve them in the most efficient way.
"You ask how radically the solution and its format can differ from the one the client came with. Long ago, there was a case in my practice where the client wanted to build an internal CRM system from scratch as he sought to speed up the paperwork flow within the company. As a result of conducting the discovery phase, we simply rearranged some employees' desks. Anyway, the client's goal was achieved!"
Cliche 3: Business analysts prioritize stakeholder needs
TRUE, BUT…
The cliche about business analysts prioritizing stakeholders' needs is generally true but can be misunderstood. That is, "prioritizing" doesn't imply blindly following every client's wish or disregarding the development team's perspective. Instead, it's about collaborating with stakeholders to uncover the best solution.
Business analysts serve as partners who help clients define their real problems and objectives. This process involves asking many questions, ultimately boiling down to the essential question: "What for?" Every product has a purpose beyond that of making money, and all businesses aim to achieve specific goals. It's the business analyst's role to extract these underlying objectives.
For instance, if a startup aims to triple its growth in the next year, the solution must be scalable, even if the client didn't initially specify scalability as a requirement. By understanding these deeper intentions, BA can ensure that the solution not only satisfies immediate wishes but also addresses long-term objectives.
This collaborative and inquisitive approach makes the resulting solution both customer-centric and technically sound, ensuring that the product meets the client's true needs.
Achieve your boldest business objectives with Binariks' software development services.
Cliche 4: Business analysts are redundant with project managers
FALSE
While there might be some overlap, their roles have very different focuses.
A project manager is responsible for the project being done on time and budget. As the name implies, they play a role in planning, monitoring, controlling, and closing out projects. Along with that, the solution can contain multiple different projects, and the whole solution being right and addressing all client's needs is a BA's main area of responsibility.
"A PM-BA hybrid is a very bad combination in one position," says Yuliia, "I'm glad that I see less and less of such vacancies now. The thing is PM is supposed to look inside the team, emphasizing project execution, while BA is looking from inside the team at a product in general, concentrating on business needs and requirements. And these approaches are just too different."
So, a good BA always knows at which point in the development process the team is and what will be their next priority. A business analyst determines the vector of movement and holds the central thread of the product on which all the requirements, tasks, and scope items are strung.
And speaking of the BA work on a project level, their primary role is having the project's scope prioritized and ensuring iterative development aligns with business objectives. They establish traceability to connect every detail to the overarching business goal and track the impact of any changes made.
In a nutshell, business analysts constantly collaborate with stakeholders to gather precise requirements and specifications, enabling the design and further development phase to proceed effectively and following a client-centric approach.
Yuliia notes, "We would not be a truly agile team without such adaptive planning, ability to make changes, and possibility of continuous improvement."
Cliche 5: Business analysts bridge the gap between business and IT
TRUE, BUT…This role of a business analyst is like that of a skilled translator. The BA must excel at translating both client's requirements and developers' suggestions into a plain, intelligible language, ensuring clear communication in both directions.
However, the thing is not just about comprehending technical terms, as it might seem. It is meaningful and helpful for a client to grasp the nature and sequence of the development process.
The BA must explain why, for example, there are no new functionalities visible within two weeks and what are the backend processes behind this situation. Lacking such a clear vision, a client may perceive some facts as mere excuses.
So, by providing client-side stakeholders with a complete picture and fostering understanding, the BA helps manage their expectations and build trust.
And it works the other way around, too: when initial technical documents are written, a business analyst and developers meet for a requirements clarification session. Despite the prepared documentation (which may seem enough for a technical specialist), the purpose of such meetings is to give developers a vision not only of what they are expected to do but also why it is necessary in a business context.
In this way, every developer's action has a clear objective. The developer may not read the product vision statement at all. Yet when they know exactly what functionality this or that solution should have in the real world, they can be more creative in building it.
Such an approach makes a work process meaningful, which is clearly beneficial in all aspects, from productivity to emotional wellness at the workplace.
Final thoughts
Business analysts play a pivotal role in IT projects, both large and small, as their expertise helps save valuable time and resources (What a universal goal for any client!).
By meticulously clarifying and documenting project requirements, they ensure a clear and shared vision, preventing misunderstandings that can lead to costly delays. Moreover, their "translation/mediation" skills mentioned above, streamline communication and foster understanding among stakeholders. Business analyst ensures that IT solutions are not just technically sound but also aligned with the client's true business needs.
As a result, clients can expect projects to progress efficiently, meet their objectives, and ultimately save both time and money, making the inclusion of a business analyst one of the smartest investments an entrepreneur can make.
Author
Co-author
Share
