Who is a Business Analyst in a nutshell
To understand the real consequences of overlooking a business analyst (BA) for your project, first let’s see what a BA is and what they do. A BA is often described as a bridge that connects the client and the development team. And by connecting, I mean much more than just relaying information from one party to the other. On the one hand, BAs speak the business language that helps them understand the client’s business needs and identify business goals. On the other hand, BAs are proficient in the technical language and can translate high-level business objectives into a set of clear and actionable instructions for the dev team.
The main focus of a business analyst’s work is requirements. But what is a requirement? A client’s notion of a requirement can be a high-level product concept or solution vision, while developers need detailed description of a system’s behavior under specific conditions. Karl Wiegers, the industry expert and the author of numerous books on business analysis and project management, identifies three levels of requirements that a BA works with – business requirements, user requirements, and functional requirements. Throw into the mix different business rules, design constraints, quality attributes, and third-party systems that a solution needs to be integrated with, and you’ll get the idea of the amount of information that a BA needs to process in order to provide a clear and concise specification for developers.
That said, even if there is no dedicated BA position on the project, someone still needs to undertake these responsibilities and activities. The exceptions are support and maintenance projects or small-scale projects with a single developer who is capable of eliciting and analyzing requirements. But if you are building a software solution from scratch, enhancing your system with new functionality or integrating with new services, having a BA on the project is a must.
In my experience, I’ve seen different setups and roles distribution, some were more successful than others. The most effective arrangements usually include:
Building a software solution without a BA is like building a house without an architect
Let’s use a common metaphor and compare building a software solution with building a house. What would happen if you undertake a construction project but decide to skimp on an architect?
Expectation gap, or this is not the house I imagined
With no architect to create blueprints and design floor plans, you will have to communicate directly with construction workers and describe your ideal house to them. However, even a seemingly straightforward definition like a “two-story cottage” can be interpreted differently by different people, and instead of a dream house you may end up with just a building that has nothing in common with what you had in mind, except for the number of floors.
The same holds true for a software development project. Without a BA, the client needs to translate business requirements directly to the technical team. However, it is not developers’ responsibility to analyze the requirements or try to find those that are incomplete or improperly specified. Instead, they start building the solution while operating on their own understanding and assumptions. And it’s not surprising that the final result can significantly differ from the client’s vision.
To mitigate the risk of building a wrong product, a BA regularly communicates with stakeholders and makes sure that everyone is on the same page. To achieve that, a BA can create low-fidelity prototypes, mockups and wireframes early on in the process to validate requirements, identify missing or hidden ones, and to evaluate design options. Such frequent stakeholder engagement helps significantly reduce the expectation gap.
Poor usability, or design decisions that make your house unlivable
Now, let’s imagine that the house built by the workers under your meticulous supervision looks exactly like the picture in your head. You are ecstatic and immediately move in with your whole family. After a few weeks you start noticing things like misaligned windows in the kitchen that do not allow you to keep an eye on the children playing outside. Or a laundry shoot in the bedroom, that had to be moved a little bit to the left to avoid the underfloor structures, now drops the clothes in the walkway.
Just like a house must be functional, safe, and serve the purpose of people living there, a software solution must be usable, efficient, and meet the needs of end users. UX, or user experience, goes beyond creating eye-catching interfaces, it focuses on how easy and enjoyable it is for people to use the product, which ultimately determines its competitiveness in the market. And the importance of good UX for a commercial product cannot be stressed enough. In my experience, I saw a client wasting a huge amount of money to build a platform that boasted a stunning UI but was utterly unintuitive and overly complex – to the point of being unusable.
A good business analyst is well-versed in the fundamental principles of UX design and regularly researches competitors to understand user expectations across similar products. Coupled with deep understanding of the client’s business, it enables a BA to act as a consultant and suggest the most optimal UX decisions grounded in best practices and industry trends. Equally important is BA’s ability to see a big picture and how modifying one system component can impact other components. So when a client wants to introduce changes, it is BA’s job to analyze the consequences and ensure that all alterations are consistently implemented throughout the entire solution.
Budget overrun, or penny-wise but pound-foolish
Once you see that the house is not what you wanted it to be, can you imagine the cost of redesign? And how much easier would it have been to make the necessary changes at the architectural design stage?
One of the most common reasons for skimping on a BA is an attempt to reduce the overall project costs. But in reality, it’s the opposite – the better and more mature the requirements are (which is the direct responsibility of a BA), the less time software engineers spend on redevelopment and problem fixing. Making changes to a prototype prepared by a BA is much faster and more cost-effective since at this point there is nothing for developers to redo. In fact, well-constructed requirements definition and management reduce budget overruns by 75%, according to the Business Analysis Benchmark research.
Lack of documentation, or a smart home with no instructions
Now, picture your cozy two-story cottage as more than just a house – envision it as a smart home equipped with multiple sensors and devices, as well as a monitoring and controlling system. And even if you intuitively understand how everything works right now, what about future enhancements? For instance, you want to have your garage connected to your smart home system to control garage doors remotely – wouldn’t it be easier to just show detailed documentation for your smart home setup to the specialists rather than trying to explain it yourself?
Having comprehensive and well-organized documentation for your software solution is another tangible benefit of engaging a BA on the project. A business analyst diligently creates and maintains solution documentation in any relevant form – Vision and Scope, Software Requirements Specification (SRS), or user stories and their acceptance criteria. And when a new talent comes on board or an entirely new development team takes over solution enhancement, the onboarding process becomes much faster (hence, less expensive) because every question that developers have regarding the solution logic and functionality has already been addressed in the documentation.
The bottom line
Running on a tight budget, it may be tempting to skimp on a BA to cut project costs. After all, a BA is not going to write code or fix bugs, and that’s what matters for a software solution, right? Well, wrong. A business analyst is a glue that holds everything together. It is thanks to a BA that a developer knows exactly what to code and can get down to it instead of trying to elicit requirements from a client.
And don’t forget that a developer’s hourly rate can be even higher than that of BA. So when developers do need to elicit and analyze the requirements on their own, it comes at a higher cost but reduced efficiency.
This is our third post in the series of articles devoted to non-development positions on a project that are required to ensure the overall project success. Just in case you missed them, find them here: