Working with requirements is an integral part of the software development process. But very often there is no dedicated business analyst within the project so either customer, project manager or QA manager has to play this role. Such a configuration can sometimes be harmful to a project. The fact is that each role has its own goals and areas of responsibility.
If one has to work with the requirements in addition to his or her regular responsibilities, a lack of time or expertise in the field of business analysis may lead to important things being overlooked. This may result in an incorrect understanding of the customer expectations by the technical team or an incorrect implementation, and this will lead to waste of time and money on rework and re-testing. And the final results of it all could be missed deadlines and an unsatisfied customer.
Of course, such problems do not occur on all projects with no dedicated business analysts. And in each case it is necessary to take into account a number of factors. We decided to see what indicates the need for a business analyst in a given project.
To do this, we performed a survey with the key project managers within our company and gathered together the most common symptoms.
Customer doesn’t have clear understanding of the final product.
Very often, the customer comes to the development team with a brilliant idea, but without a detailed understanding of how the application should be implemented. What capabilities it should have to please users and meet the expectations of clients. In this case, the best practice is to conduct a discovery phase at the beginning of the project. A business analyst will study the client's needs, target audience, and competitors. They will gather and document the initial requirements for the application. This will give the customer a clear understanding of the expected functionality and will help the technical team to make a more accurate estimate of duration and the cost of future development. Also, the documents that were collected during the discovery phase will significantly reduce the time to clarify the requirements during the creation process.
A lot of stakeholders on the customer side
If there are many stakeholders or groups of stakeholders on the customer side, and each of them is a source of requirements, certain troubles may appear in the course of work on the product, such as:
Requirements that contradict each other
Missed requirements from some stakeholders
Missed groups of stakeholders
Incorrect prioritization of the requirements
And other problems that can lead to very unpleasant consequences.
The main goals of a business analyst in this situation are to identify all groups of stakeholders and to assess their needs. Then, carefully collect all requirements to analyze, organize, and prioritize them.
The next indicator is the level of complexity of the requirements. It is not easy to define, but we can give a few examples:
The requirements are massive with a lot of rules and exceptions
The requirements for projects with a complex hierarchy of users and different levels of access to functionality
The project belongs to an industry that is little known by the developers, with special terminology and rules that seem obvious to the customer, but does not appear so to the developers
Of course, there are a lot of examples like the ones mentioned above and they all require a dedicated person to handle all the requirements, as they need to be clarified and described in detail in the documentation.
Large scale / long term project
And the last one in this article, but a very important factor is the size and duration of the project. The more people involved in the development process and the more features implemented within a unit of time, the higher responsibilities the business analyst has, as well as the requirements for all project functionality should be analyzed and documented then implementation. In addition to this, the business analyst must ensure that all of the many team members know where to find the latest documentation, each equally and correctly understand the requirements and have the opportunity to obtain answers to their questions any time they need.
Speaking about long-term projects, it is difficult to work with frequently changing requirements without a business analyst. The job of the BA here is to evaluate the impact of these changes on the overall system and report on any controversy before the changes are implemented. Also they should keep a history of changes and ensure that all team members are aware of any new developments and understand them correctly.
In large and long-term projects, changes within the team happen quite often, and it will be much easier to introduce a new team member to the if relevant documentation and someone (namely, the business analyst) who knows all the details of the application are in place.
The benefits of having an analyst on the project are not always obvious to the customer, but they can be significant. If it is necessary to change functionality and the requirements are not fully described, no one has a clear idea of the final product, and no dedicated business analyst, it is time to bring one onboard.