The role of a business analyst in a software development project (and if you really need one)

Having been a business analyst (BA) in software development projects for four years, I’ve come across many stereotypes built around this craft. Some people take you for a scribe that generates documentation. Few others understand your role as a translator between the business and the tech people. While both those images are partially true, the role of an analyst is much deeper and more
complex and has a cross-sectional influence on the whole project. 

This is an honest article that’s been on my mind for quite some time. I want to share with you the real scope of BA work, sketch what the real value behind it is, and help you assess if you need them in your particular project. Let’s start with the last question.

Does your project really need a business analyst?

A BA is the customers’ greatest ally in building a satisfying solution. They link two worlds because they are both an advocate for the clients’ needs and a part of the project team. Their presence improves communication with the client, gives faster and smoother delivery, and contributes to the satisfaction of both sides.

Cases and scenarios

As a progressive web app (PWA) BA, I’m usually involved in projects in the following scenarios:

• When the project team is built only of people from your company and only the owner and field experts act on the client's side.
  
  
• When the project is complex in terms of architecture. As an example, you might want to replace the back-end platform, and it requires migrating the processes into a new one and taking into account the PWA front end, custom front processes, etc.
  
  
• When the client doesn’t know the business goal of the project and doesn’t know what they want or how to achieve it.
  
  
• When the project includes previously unimplemented functionalities or an area. For instance, when, instead of an eCommerce platform, we’re dealing with a banking or telecommunications platform where the processes and legal requirements are completely different.
  
  
• When the project requires documentation for the maintenance phase and nothing was written before.

In practice, it all usually comes down to the following two options:

Scenario A: You don’t have a clear vision and documentation

The truth is, your tech team can manage without a BA. They can always do the additional work that is normally outside of their scope. Some of the architects and developers are well qualified to take over the business analysis role and fill out all the paperwork. 

However, you have an important question to ask yourself at this point. Do you want your extremely expensive software development experts to handle these analytic, cross-sectional, time-consuming tasks? 

Without the analyst having responsibility for these tasks, they fall on the technical leader and the developers. It can affect not only the duration of the project but also the quality of their work. It can draw them away from the development itself and multiply your costs.

That being said, your tech experts taking on additional analytical work can only happen with a tech team that is business savvy. In less experienced teams, the tech experts might be less likely to understand your business well enough to steer the project towards a positive business outcome. An analyst performs those mundane tasks, learns your needs, and applies their own experience to make sure you get what you paid for. By doing so, other members of the team don’t have to.

Scenario B: You have a clear vision and documentation

Now, let’s say that you, as a client, have a clear goal and vision. You understand what you need and know what you want it to look like. You even have complete documentation and know-how to explain all this to a technical team. In this case, you’ve probably done most of the BA work yourself. An analyst won’t be necessary to launch this project, but they may still prove useful later on. 

What’s the best stage to get a business analyst onboard?

The easiest way to understand what a BA can do for you, and when they should do it, is to see their scope of work. As the project develops, a business analyst role includes:

Pre-development phase

A business analyst has to understand clients' needs and analyze the company's specifics and processes. It’s the way to make sure that the project delivery is well aligned with its business goals. 

Gathering requirements

To gather this knowledge, a business analyst usually sets up a series of meetings with stakeholders on different levels and positions on the client-side. It’s crucial to get a thorough understanding of their expectations. In many projects, some of those expectations are left unspoken up to this point, and they may be far from what’s in the initial brief. 

Building documentation

Creating documentation is a much more creative part of the job than it seems. It’s not just putting on paper the information that’s been provided. It’s building a functional, complex business concept. 

You have to come up with a coherent and precise vision, and a couple of ways to achieve it. You present possible solutions to the client and help to estimate budget, deadlines, timetable, and priorities, and pick the final course of action.

Of course, documentation is the medium for all those analyses and decisions. By creating that documentation, a BA makes sure that the requirements and needs reported by the client don’t perpetuate mistakes in processes, practices, and procedures but instead lead to their improvement.

Creating the right relationships from day one

It’s the analysts’ job to set things straight from the beginning. It’s a crucial role in building the solid, positive relationships needed between the project team and the client. Anyone working on software development projects will tell you that it can make or break a project because it impacts the development process, management, everyday work, and experience of both sides.

The client and the team often talk in different languages, and I don’t mean English and French. Even more impactful are the conflicts between the technical and business needs. Proper communication is the key to building great projects together. Both of the parties need the help of a BA to understand each other.

In many cases, a simple change requires a major redesign in the code or architecture. This increases costs and challenges the timeline of the project. The analyst has to consult about the possibilities and limitations of the chosen tools with the architect or technical leader. They have to inform the client about the consequences of such changes. It’s a good practice to suggest alternative solutions leading to a similar outcome but limiting the negative impact on the project delivery.

Development phase

During the development, the role of a business analyst is usually limited to helping set up the tasks in Jira and occasional consulting just in case. 

Maintenance 

If you have a well-researched and documented project, there’s no need for a BA to join during the final phase of the project. They can be useful in case your project went down a rough road and drifted away from the initial documentation. It’s crucial to get it right at this point and create decent documentation to hand over to the maintenance team. 

To sum up: Business analysts take over tasks the software developers hate

The development process is rarely straightforward, and agile projects follow a winding course. The presence of the analyst contributes to the success of the project and makes it more business goal-oriented and less chaotic. 

Business analysts in your project will let all the parties: 

• Look at the project from a new perspective.
• Get rid of additional mundane tasks.
• Keep the documentation tidy.
• Set a clear common goal.
• Unify all the efforts.
• Avoid misunderstandings.
• Improve clients' experience through the process.

Assisting teams in delivering software is a great opportunity to witness how a project unfolds from a simple insight into a tangible product. With a BA on board, you can simply be sure that someone watches over your needs, and they won’t mess things up. That’s the highlight of this job: hatching a valuable solution despite all odds and making sure the project delivers what’s promised.