Business Analyst, and why you need a BA on your IT project

Nowadays, it is rather difficult to find a company that does not use some kind of software to run its business operations. As a result, the popularity of software solutions has led businesses to raise their expectations and to require software solutions to do much more in a shorter period of time. This is exactly why throughout the years the role of a business analyst has become inevitable.

Business Analyst on a software project is the professional who is generally associated with requirements elicitation/analysis. These agile workers straddle the line between IT and the business to help bridge the gap and improve efficiency. The analysts in this role generally begin their work once a given IT project has been initiated. They are the ones eliciting requirements from stakeholders, analyzing and documenting them in BRDs (business requirements documents), and creating functional specifications. In this role the analyst may also interacts with the development and quality assurance teams.

Role Description

What a Business Analyst actually ‘does’ greatly varies depending on what project (s)he is working on, what stage of the project is in progress, the stakeholders involved or even the company itself. Still it is possible to highlight the set of main responsibilities that can be considered the backbone of the tasks a BA will mainly fulfil on the project:

Identifying business needs. To understand which direction to choose, a Business Analyst should clarify the primary purposes of the future product, and understand the business problem a client wants to solve. So the main aim here is to communicate with stakeholders to define their business needs and extract their requirements for what must be delivered. Quiet often stakeholders of one company have different needs, goals and knowledge of the business. So it’s the job of a BA to bring all this knowledge together, analyze the information gathered and provide a clear understanding and vision for everyone to work with.

Transforming the business idea into clear technical requirements. BAs gather the business’ required conditions and capabilities, document them in a consistent, complete and, above all, useful way for the team that will eventually design and deliver the solution. Simply saying, BAs interpret business requirements into systems and technology language that can then be easily understood by a technical audience, and describe each technical requirement as use cases or user stories and wrap them up into SRS (software requirements specification).

Validating requirements with both software engineering team and stakeholders to make sure that everyone is on the same path. During this phase it is also vital to determine what additional information is needed, what key details are missing, and what potential impacts and challenges to the solution and/or other projects can be faced.

One can say these are the major tasks a BA handles on the project, and for more traditional models like, for ex., Waterfall, this is indeed so, as a Business Analyst communicates with the stockholders, gathers the requirements, translates them to a technical team and then… his job is finished. However, when a software company is following the Agile methodology, a Business Analyst can take an active part throughout the whole development process.

When the project is Agile a BA can, for instance, help to formulate the main backlog ensuring that all business aspects, discussed earlier, are reflected. Or, for example, when a project grows more complex or starts to veer off track, a Business Analyst can step in and take on a stronger presence within the team making sure the priorities are aligned and work well to remove any speed bumps. In this case, while repeating the tasks on different stages of a project, a BA makes sure what is being actually built fully meets company’s expectations.

But what is important here is this extra attention should not be sustainable, as this dilutes the effectiveness of a Business Analyst, who now has to spend less time evaluating and more time helping other teams. It’s more productive when a BA jumps in to take over the dev team from a day-to-day task management aspect, or is involved when it is really needed, and then takes a more hands-off approach for other development goals.

Benefits a Business Analyst brings to a project

Business analysis can bring a maximum efficiency to a project team, but this can sometimes be overlooked and seems counter-intuitive that adding a business analyst to an IT project development team will save money.
Nevertheless, a BA pays for himself by helping sponsoring organization and the development team to focus on business value & appropriate goals throughout the project.

Right below is a graphic illustrating how requirement changings at various phases of a software development project affect the costs.

So, the cost of changing or adding requirements is lowest when done in the earliest project phase – analysis. If you do not begin a project with good business analysis, it will come back to haunt you at greater and greater expense down the line.

But when done right, business analysis can substantially increase the benefits of a software development project in two major ways. They are:

• Increased value of the solution. The graphic below shows how proficient analysis contributes to the value of a solution and project success.

• Discovering business needs and requirements, hidden behind expressed desires, that contribute directly to the value of the solution;
• Keeping the development team and stakeholders focused on implementing requirements with the most potential benefit;
• Eliciting the actual problems the business is trying to solve to eliminate requirements with minimal value or purpose.
• Reduced implementation costs. A large part of a business analyst’s job is to reduce company costs, and there are several ways how it can be achieved:

• Finding more cost-effective solutions.
  Maybe there are tools a company can use that are already there. Maybe there’s a business process change that can get a certain amount of the way there, and so on. It doesn’t always happen. But if it is possible, a Business Analyst will help to find it out.

• Reduction of requirements churn,
  or the time it takes for the business community to figure out what it is they actually want. It isn’t like a line item cost on a budget. But if requirements meetings, especially those with high-level stakeholders in the room, are duplicated again, and again, and again to discuss essentially the same issue and never getting to a solution, that is an expense that a company is definitely taking on.

• Reducing rework.
  It doesn’t always work that way, but sometimes some functionality that maybe seemed simple in the beginning, gets complex as like stakeholder requests come in, defects come in, change requests come in, and a dev team has this re-work, needs to go back and revise the same code, the same implementation again, again, and again. But if a company adds some analysis up front to figure out clearly what is needed, that re-work time should go down.

• Creating a full and shared vision of the project.
  Having developers interacting with stakeholders and participating in lengthy requirement meetings isn’t productive. Developers often want to dive into a project or idea before they fully understand the scope. They can see the end product but might not have realistic expectations for how it gets done. So this is where having a dedicated Business Analyst can help everyone within the project to come up to a common vision of a future product, while identifying the risks and the processes needed to make the dream a reality.

So, when do you need a Business Analyst?

Now, having the idea of what a Business Analyst is, and his role on the project, let’s draw the line what projects a BA can be a good fit for.

You definitely need to onboard a dedicated Business Analyst when you have a business idea or a problem to solve, but still no requirements and no structured details.

You don’t need a BA that much if you operate in a specific business domain where requirements are unlikely to change in the next ~5 years and can be formed as SRS documentation only. In this case, you can focus on your solution development. Such cases need a project coordinator rather than a BA, whose role you may substitute with a business owner elaborating the requirements.

Conclusion

No doubts, hiring a dedicated Business Analyst can make your project more successful. While the development team outlines the technical solutions, a Business Analyst provides information, clarifies requirements, asks/answers questions, and eliminates obstacles. Yes, onboarding a Business Analyst on the project and letting him follow all the procedures take time. It’s not like you put a BA in and, snap, s/he comes up with the requirements, stakeholders and the team are happy, and ROI shoots up.

But the project is going to take definitely less time and fewer costs than if you don’t have somebody who are in charge of facilitating the requirements and ensuring that the technical solution is developing forwards to meet the stakeholder’s expectations.

One of the biggest mistakes that companies make is asking a project manager or a programmer to take on BA responsibilities. They don’t set aside a dedicated specialist to manage requirements gathering and analysis or require their BAs to wear too many hats.

Although business analysis is a role that involves many activities throughout the project, this does not mean that it can replace other roles during the project life cycle, and vice versa.

A proper business analysis is an inevitable step if you want to be sure you receive the best version of the product which will boost your productivity and allow you to beat your competitors.
So, if you want to establish a more predictable project lifecycle and development process as well as to increase project value and cut off the costs, it is the right time to onboard a dedicated Business Analyst. And if your IT team already has one, make sure you are using this BA for the right projects and the best way possible to grow your organization.

Thanks for reading and share your opinion in the comments below!