Could a Project Run Without a Business Analyst?

To design the right products and services, you need the right team. Usually, a product development team includes specialists from multiple areas and its composition depends on each particular project need.

While the need for an engineer or designer seems evident to the client, the relevance of the other team members might be put into question. In this article, we will consider the role of a business analyst on a project and explore whether an individual specialist should be involved to conduct business analysis.

‍Why should I engage a business analyst on a project?

Actually, you don’t have to. But you should understand:

If there is no person with a BA title on a project, someone else will perform business analysis tasks anyway. 

It could be a project manager, designer, engineer or quality assurance specialist — it’s about the role, not a title or a position.
Creating a product requires defining clear goals and objectives, keeping all the requirements up-to-date, and tracing new requests back to the user and business need, understanding all dependencies, etc. This means, someone will do the business analysis job anyway, but the question is how fully it will be covered.

‍Business analyst: definition, role and responsibilities

To answer the question of whether your particular project needs a BA, let’s first understand what this person is responsible for.
According to the BABOK Guide, the globally recognized standard of practice for business analysis, a business analyst is the person responsible for enabling change in an enterprise by defining needs and recommending valuable solutions to stakeholders. The BA has to elicit requirements and knowledge from stakeholders or other sources, discuss available options with the development team in order to come up with the most suitable solution.

There are hundreds of methods and ways to perform these activities, which is why there are many variations of the BA’s role definition. We intentionally use the word “role” instead of “position”, which makes a significant difference in answering the question. Most likely, you have seen that a set of BA responsibilities differs depending on the country, company, and project specifics. This role may even differ across projects run within one company.

Some projects require conducting user research and interviews, others — running workshops with the key stakeholders, building logical data models or visualizing business processes with diagrams. Sometimes BAs have to create a low fidelity prototype to interpret and approve requirements, gathered from the product owner.

What projects definitely need a business analyst?

Based on the cases we experienced at Selecto, below we list the types of projects where adding a business analyst to the team is necessary:

The client has lots of ideas about the product but cannot provide the team with a precise list of features and requirements.

In this case, a business analyst has to ask a customer the right questions and interpret data to help the product development team deliver the right solution.

Here is a simple example. Let’s imagine that a customer wants to create a platform that allows users to organize online events. He describes the desired functionality briefly focusing on the core features (e.g. creating, editing, publishing, and canceling events).

Before designing the UX, the team needs as detailed a description as possible to be provided by the product owner. Even the smallest details matter to understand the context deeper. In this case, the answers to the following questions should be provided: What types of users could access each particular feature? Who and how is able to manage user permissions? Should there be any moderation before publishing? Will it be done automatically or manually? If automatically – based on what criteria? Should the reports be added? How fast should they be generated?

The business analyst processes the answers provided by a client, analyzes the business and user sides, anticipates different alternatives, exceptions, rules and then validates them with the client. Once it’s all approved, BA documents and passes the info to the design and development team.

‍The project has multiple (3 or more) stakeholders and there is no consensus between them.

Since every stakeholder is a source of the requirements, a business analyst has to collect all of their suggestions, analyze, systematize and prioritize requirements carefully. Sometimes a BA even initiates and facilitates decision-making sessions. In case there are difficulties, the BA identifies people to discuss an issue, involves external specialists to get an expert view, traces user requirements back to the original business goal in order to assess value, risks and dependencies.

‍The project scope is huge, complexity and risks are high.

Projects with a complex user hierarchy and different levels of access to functionality tend to have massive requirements, with a large number of exceptions and restrictions. Moreover, requirements for a system might look unclear to implementers, because of special terminology and rules that seem obvious to the client but are new to developers.

For example, some industries are very regulative from a legal point of view. It means that even a tiny detail missing may cause losses for the company. The BA’s role here is to learn the domain — new terminology and specific processes and then translate clients’ words into understandable for the team’s functional and non-functional requirements.

‍The project is long-term.

Long-lasting projects are likely to have a lot of information to be recorded and kept: from requirements to change requests, from selected approaches to workflows to simple references. Often team members may have concerns about the workaround for a particular edge case. What is more, the team composition from both sides could change, especially when the project lasts 5-6 months or more. In both cases, a BA performs a knowledge holder role managing data and onboarding new team members.

‍The project requires detailed documentation.

Designing products for highly regulated industries such as healthcare, finance, governmental services always requires documentation. Some companies have their own internal standards for documenting software solutions and want them to be followed. Another reason when a project requires extensive and precise documentation is a planned gap between the project stages (e. g. between UI design and coding). In this case, all info should be kept carefully, always available and understandable for the next rounds.

What if there is no business analyst assigned to a project (a real case included)?

In case you decided to follow an approach when one person combines two roles (e.g. a product designer performs the tasks of a BA), you should be aware of the following risks:

• blurred focus and decreased efficiency: specialists performing the BA’s job would have to switch between different areas all the time. Trying to multitask and keep everything in mind they become less productive and have less time to anticipate all possible edge cases or alternative flows;
• lack of relevant experience and skills could harm the quality of the work;
• scope creep: instead of thinking about legal restrictions or functional dependencies for a new feature, the designer or developer wants to jump into the creation process asap;
• this kind of job might demotivate other team members, as creative or tech minds aren’t so into precise documentation or conduction of lasting research – what BAs are passionate about.

Let’s base on the facts and consider the real case we experienced at Selecto. On one of our recent projects in the area of healthcare, adding a business analyst to the team helped us to increase the designer’s time for the UX design process itself by 27,8% (see a diagram below).

Initially, working on their own, designers spent about 45% of working time on communication, mostly — to gather or clarify requirements (average monthly working time – 160 hours). The thing was, that there were multiple stakeholders on the client-side, often their requirements contradicted each other, and as far as the product was live, we constantly received feedback from users and had to implement lots of small and big improvements.

The business analyst took a communication part of the job which allowed the design team to focus on user flows and visual interface. The BA specialist also added value by carefully documenting everything, brainstorming on better ideas and researching competitors more deeply.

According to statistics, provided by the National Institute of Standards and Technology, the cost of a mistake increases as the project goes on. To compare: the cost of the correction at a discovery phase is 10 times lower than the same at an implementation stage and 50 times lower than that at a testing stage. So investing in high-quality requirements processing at the very beginning makes sense.

Projects that do not require a BA from the vendor side

As we said, a business analysis activity has to be performed anyway, still, there are some projects with no need for engaging a dedicated BA from the service provider’s side.

The client already has a business analyst on their side.

No matter what title the person responsible for business analysis has — be it an analyst, product manager or product owner, each of them could have responsibilities very similar to a classic BA. It is important to clarify here from the start whether all of the needed tasks would be covered by this person.

The project is short-term and has no complex user hierarchy or functionality challenges.

When the project goal is to uplift an existing product or move it to the new platform keeping current logic, or when stakeholders are completely familiar with user flows and all possible scenarios, or when there are lots of similar solutions on the market – in these cases hiring a business analyst might be not necessary. But again, it depends on the particular project need.

All the basic project info is already gathered.

In this case, all the information about the domain, clients’ business, clients’ personas, requirements analysis, system logic description, and its interconnections are documented and could be shared to the new project team.‍

Conclusion

To sum up, every project implies performing business analysis activities. Sometimes, this role has to be performed by a person specialized in this area, sometimes it could be delegated to another team member — designer, engineer, project manager or other. To decide how business analysis work should be performed on your project, you should consider your particular need and project specifics.