When should a business analyst be involved in a project?

Requirements management is an integral part of the software development process. The advantages of having an analyst in a project are not always obvious to the customer, but they are invaluable. If sometimes you have to redo the functionality, the requirements are described in part, no one has a clear idea about the final product and where you can get the actual description of the requirements, it's time to think about attracting a business analyst.

However, very often there is no dedicated business analyst in the project, and the project manager or the QA manager are partly responsible for his duties. Such a combination can sometimes hurt.
')
The fact is that each role has its own goals and areas of responsibility. If PM or QA-manager is forced, besides the main responsibilities, to take on the management of requirements, due to lack of time or qualification in the field of business analysis, something can be missed. As a result, there may be an incorrect understanding of customer expectations, incorrect implementation, unjustified time and money spent on reworking the functionality and retesting. In the end - the failure of the timing and unsatisfied customer.

Of course, such problems do not occur in all projects where there are no dedicated business analysts. And in each case, you need to take into account many factors. We decided to understand which indicators may suggest that we need to think about attracting a business analyst. For this, employees of the DataArt Business Analysis Competence Center conducted a survey of key company managers and obtained the most common signs.

The customer has no clear idea of ​​the final product.

Very often, the customer comes to the development team with a great idea, but without a detailed understanding of how this idea should be implemented. In this situation, the best solution is to conduct the discovery phase at the beginning of the project. The business analyst will examine the target audience of the future application, customer and competitor expectations, collect, analyze and accurately document the initial requirements for the product.

This will help the client to have a better understanding of the expected functionality, and the project team will be more careful in assessing the time and cost of development. The documentation obtained during the discovery phase will save the team time to ascertain requirements during the development process.

Many interested parties on the side of the customer

If there are several stakeholders in the project, and each is a source of requirements, the following difficulties may arise:

• Excess requirements.
• Contradictory requirements.
• Missed requirements.
• Invalid prioritization.

And this is not a complete list of possible problems.

In this case, the business analyst must carefully collect the wishes of all stakeholders, analyze them, systematize and prioritize them.

Challenging requirements

The level of complexity of the requirements is not easy to determine unambiguously. But there are several examples:

• The requirements are quite extensive, with a large number of rules and exceptions.
• Requirements for projects with a complex hierarchy of users and different levels of access to functionality.
• Requirements for the system in the industry, little known to the performers, with special terminology and rules that seem obvious to the customer, but do not occur to developers.

There are, of course, many more examples, and in such cases the requirements should be clarified in detail and described in detail.

Large / long projects

The last but very important factor is the size and duration of the project. The more people involved in the development process and the more functions are created per unit of time, the more responsibility the business analyst falls on.

For large and long-term projects, the benefits of a dedicated business analyst are noticeable, especially in the context of frequently changing requirements. For a long time, new requirements may come up or old ones may change.

The task of the business analyst is to assess the impact of these changes on the system as a whole and report on inconsistencies before the changes are implemented. In large and long-term projects, a change in the composition of the team often takes place, while it will be easier for the new person to understand the existing functionality in the presence of relevant project documentation and a person who knows all the details of the application.

Author: Nadezhda Tarasova, Senior Business Analyst.