When to engage business intelligence 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 you sometimes have to redo functionality, the requirements are partially described, no one has a clear idea of the final product and where you can get an up-to-date description of the requirements, it's time to think about involving a business analyst.
However, very often a project does not have a dedicated business analyst, and the project manager or QA manager is partially involved in his responsibilities. Such a combination can sometimes do harm.
The fact is that each role has its own goals and areas of responsibility. If a PM or QA-manager is forced, besides the main responsibilities, to take over the management of requirements, due to lack of time or qualifications in the field of business analysis, something can be missed. As a result, a misunderstanding of customer expectations, incorrect implementation, unjustified time and money spent on redoing functionality and re-testing may occur. As a result - a failure to meet deadlines and an unsatisfied customer.
Of course, such problems do not arise in all projects where there are no dedicated business analysts. And in each case, many factors must be taken into account. We decided to understand what indicators can suggest that we need to think about attracting a business analyst. For this, the employees of the DataArt Business Competence Competency Center conducted a survey of key company managers and received the most common symptoms.
The client does not have a 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 carry out the discovery phase at the beginning of the project. The business analyst will study the target audience of the future application, the expectations of the customer and competitors, collect, analyze and accurately document the initial requirements for the product.
This will help the client to get a better understanding of the expected functionality, and the project team to more carefully evaluate the time and cost of development. The documentation obtained during the discovery phase will save the team time to clarify the requirements during the development process.
Many stakeholders on the customer side
If a project has several stakeholders, and each is a source of requirements, the following difficulties may arise:
- Excessive requirements.
- Conflicting requirements.
- Missed Requirements.
- Incorrect 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.
The level of complexity of the requirements is not easy to determine unambiguously. But there are a few examples:
- The requirements are quite voluminous, with a large number of rules and exceptions.
- Requirements for projects with a complex hierarchy of users and a different level of access to functionality.
- Requirements for a system in an industry that is not well known to performers, with special terminology and rules that seem obvious to the customer, but do not occur to the developers.
Of course, there are much more examples, and in such cases the requirements should be clarified in detail and described in detail.
Large / long-term 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 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 tangible especially in the face of frequently changing requirements. Over a long development period, new requirements may come or old ones may change.
The task of a business analyst is to assess the impact of these changes on the system as a whole and report inconsistencies before the changes are implemented. In large and long-term projects, the composition of the team often changes, while it will be easier for a 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.
Posted by Nadezhda Tarasova, Senior Business Analyst.