From the vast experience, we have gathered during the development of the projects for our customers, we can state one thing for sure. If the costs need to be cut, the last place you want those cuts to happen is the Business Analysis part. When you think about software development, you most probably don't realize how many non-technical people are involved to ensure a stable and on-time delivery of the code. In this article, we will take a brief look at the responsibilities, and daily duties of Business Analyst - a person, whose main responsibility is the measuring and assessing how your vision should be turned into reality.

Approach with caution

Often we are faced with customers having a really defined idea, and a mindset to complete it as it appears in their vision. At first, such a well-described concept seems like the perfect project to develop, but over the years we have learned that this assumption is far from truth.
A common problem with a described situation is that Product Owners tend to float afar with their assumptions and fixate themselves on particular concepts, losing a sense of scale and even reality at some point. Whether that is the case has to be verified every single time.

Enter - The Business Analyst

The first and most important role of a BA is to verify if the problem we described, occurs in the case he is analyzing. To do that, we delegate a specialist or a team of specialists to thoroughly go through the project's documentation, and cross-reference it with the existing systems, already developed components, and also - business environment of your enterprise. It's essential to learn what your app, platform, or system is designed to achieve. You also need to know by what means and with what kind of approach it will be done. But it's also essential to map your organization - in order to provide seamless delivery and deployment - we need to know who makes the decisions that apply to our cooperation, how does he decide on the course of action, who are the stakeholders, and even who has the power of influence.

After this phase of work is done, a proposed road-map is created, that after receiving approval, will be a guide for the actions we take over the course of the whole project.

Verifying the existing

Some contracts that we sign, require us to re-develop or upgrade an existing system. In this particular case, the BA has even more responsibilities. Apart from completing all the steps we have already explored, there is a very complex part of analyzing what is already out there. Now the specialist serves as an optimizing party - taking in the account all that is known, his role is to create a scheme that would enable the development of the product that in the end will simplify, and - let us repeat the keyword - optimize your business, in the effect, having a positive effect on the revenue.

Switching the roles

In the ideal world, the majority of the work of the BA would end there and then - his analysis is delivered and the development can enter the planning phase. Basing on the knowledge the team has gained thanks to BA's work, a Project Manager would then pick-up the lead and begin the scheduling. In reality - many software houses, including ours, mix the role of BA and PM in the following stages. The reasoning is simple - Business Analyst has spent a lot of resources to learn everything about the vision and the customer himself. He is the perfect person to fill the role of a PM, that basing on his assessment, can create a perfect "battle-plan". Of course - there's a difference in required competencies, and only the best BAs/PMs can efficiently merge those roles - but that's one of the keys that we use when we seek out new talents at codelabs.rocks.

In the case of all past projects which did require a "hybrid" approach to Project Management and Business Analysis - we delivered products that did exceed the customer's expectations.

Wrapping up the BA role

Despite the common misconception that is roaming freely out in the wild market - the BA is NOT a "simple middle man". He is the LINK, between the developers and the customer. In addition, when he enters the PM role, he remains such a link, during the whole lifespan of the development process. Knowing the customary "A chain is only as strong as it's weakest link", we will risk a statement that none of the customers can afford to have a weak link between them and the developers - so, our dearest Project Owners and Customers! Do not be afraid to spend resources on BAs!