A successful IT project is the result of the planned, well-coordinated, and high-quality work of a team of specialists. What do planned processes involve? a vision of a future solution is worked out; there is an understanding of the basic functionality and improvements; a roadmap for project implementation is created; the composition of the team is determined: the number of specialists, roles, and dates of involvement; the team is provided with tasks for the upcoming sprints, and subsequent ones are gradually being worked out. Well-coordinated work is when each participant contributes to the common goal, without creating downtime or delays. High-quality development means that the team participates in the analysis of requirements and is involved in the discussion of upcoming tasks - for example, at grooming, where risks and potential problems are highlighted. As a result, the team chooses the best solution. When reaching out to an outsourcing company, a customer is mainly interested in developers. Still, they should consider other equally important participants in the software development life cycle (SDLC). Now let’s imagine a team of ten “programmers only” who have the task to create, for example, a fitness app. Who of these geniuses will communicate with the customer and find out the requirements? Who will determine which features to implement first and which ones to implement later? Who will be responsible for achieving business goals? Who will be able to determine the real needs of users or correctly understand the business idea of the customer? If developers are the only specialists engaged, there is a high probability that the product won’t satisfy all the user needs, as none of them would spend time on analyzing the target audience. Who will communicate with the business? Developers approach the clarification of requirements too narrowly and technically. As a result, the customer receives a product that is completely different from what they really needed. Finally, any development should be planned, and sprints should be fully packed with elaborated tasks. This is necessary in order to release urgent valuable functionality during each iteration. If developers grasp for tasks without any order, they will eventually accumulate technical debt. If trying to clarify the customer's requirements during a sprint, they won’t be able to meet the deadlines, which can cause a significant delay in product release. Consequently, the plans will collapse. Users are not satisfied, so the business is not making profits. Well-coordinated work is out of the question because everyone is in their own bubble. High quality is out of the question too - shortcomings in requirements and implementation of flawed or unnecessary functions will have consequences. And the cost of fixing such flaws, as Microsoft calculated, increases from five to two hundred times as we move towards the end of the SDLC. Thorough planning and comprehensive analysis will help a business avoid serious losses. According to McKinsey, 17% of IT projects are so unsuccessful that they lead companies to bankruptcy. Did you know that almost half of all developments exceed their allocated budgets, and 7% of projects exceed their allotted time? Conducting a discovery phase can improve the situation - as a result, development costs are halved and the likelihood of meeting deadlines increases by 75%. Fortunately, chaos can be easily avoided by including a kind of superhero - a Business Analyst - in the team. Let's figure out what helps this specialist keep order and what benefits they bring to the business. Who a Business Analyst is and when this specialist is needed A Business Analyst is a kind of intermediary between the business and the development team. How does this specialist fulfill this role? 1. Communicates with stakeholders and gathers requirements. The Business Analyst acts as a liaison by communicating with stakeholders to extract product requirements. In this case, this specialist simultaneously solves several problems. First, the Business Analyst documents the requirements so that the development team can build a relevant product based on them. Next, they help stakeholders analyze their vision and make the best product decision. In addition, the Business Analyst saves developers time so that they can be engaged in implementing a project instead of spending hours communicating with the business. The Business Analyst can both participate in building an app from scratch and propose an extension for existing software. 2. Combines the skills of Sherlock Holmes and a marketer for business analysis. Business Analysts are also involved when market research services are demanded. The specialist helps the customer correctly determine the target audience of the product and the true needs of users. The Business Analyst delivers competitor analysis services to see which competing products are poorly implemented and which products can be considered a successful example (SWOT ANALYSIS). Often, to refine the current application, it is necessary to study what is available at the moment in order to understand how the software should be transformed (AsIsToBe analysis and/or gap analysis). 3. The Business Analyst is a bit of a writer and an artist. Not in the direct sense of these words, of course. Having gathered and analyzed the requirements, the Business Analyst documents and always submits them to the responsible stakeholder for review and approval. Sometimes, the Business Analyst illustrates their activities with diagrams: they draw a general flow or specific diagrams with data about users and the functions available to them, create mockups of the future user interface, and so on. 4. Knows how a customer can make more money with fewer expenses. Perhaps the most valuable superpower for the business. Based on the results of market research and the customer’s resources, the Business Analyst can outline new opportunities that the customer would never have thought about. Our superhero doesn’t blindly obey the requests of the business owner but offers the most useful solution with the lowest cost and maximum profit in the future. After all, business goals can only be achieved if user needs are satisfied. A good product ultimately yields profits for the customer. Summarizing the above, the key capabilities of the Business Analyst before product development starts are as follows: extracting requirements from documents or presentations by communicating with stakeholders; analyzing and processing requirements with the use of various methods (User Stories, Users Cases, SRS, etc.); documenting requirements with diagrams, prototypes, and other artifacts; reviewing and approving requirements together with stakeholders, developers, QA engineers, and other competent specialists. The Business Analyst in the SDLC: the global source of product knowledge One would think that the Business Analyst’s work is done and it's time for other employees to join the game. But the superhero’s activities are not limited to the above. The Business Analyst is one of the backbones of the SDLC. This professional is responsible for the result and should be as concerned as the owner of the product. Let's see what the Business Analyst does at each stage of the SDLC. Stage 1. Pre-sale — establishing contact with the customer. Pre-sale is an important stage in getting along with the customer. The Business Analyst explores what their IT company can offer to the customer: makes a list of the functionality of a future application, prepares a team estimation, and takes into account other important aspects. At this stage, the Business Analyst is needed to create the correct vision of the product, cover it in as much detail as possible, and perform functional decomposition, based on which developers will conduct estimation. Stage 2. Requirements’ analysis. The details of this stage are described above. The Business Analyst conducts a discovery phase, where a deep analysis of the requirements of the future functionality and accurate estimation are required. Stage 3. Implementation. At this stage, the Business Analyst provides programmers with elaborated, analyzed, and approved requirements during each sprint. This ensures that there will be no chaos during the project and the least number of bugs will penetrate into the product. Stage 4. Testing. Since QA specialists are guided by the product requirements, the Business Analyst’s participation in the testing stage is mandatory. If a QA engineer has any concerns, the Business Analyst will investigate the bug and determine whether it is a defect that needs to be “cured.” The Business Analyst will take control of the error and think of how to prevent it from emerging again. Stage 5. Release. The Business Analyst monitors how consumers use the product. This expert gathers information and reviews, communicates with the support service, and analyzes what can be improved in the application. These desires are taken into account in the next sprint. Thus, the team creates a better version of the program that is more useful and valuable to consumers. Stage 6. Maintenance. Developers and other specialists will have many questions. The Business Analyst, participating in all stages of the project, is the global source of product knowledge. That’s why everyone can seek valuable advice from them. The Business Analyst? Why include one more specialist in the team? We’ve already got a Project Manager... It may mistakenly seem that the role of the Business Analyst can be filled by the Project Manager, as they work with customers too and know all the nuances. However, comparing these professionals is the same as confusing, for example, a designer and foreman on a construction site. The designer decides which wall the entrance door will be in, how many windows the house will have, and so on. Thus, all stages of construction will be safe, and the building will meet certain standards. The Project Manager can be portrayed as a foreman who supervises the actions of construction workers so that they build houses according to the project plan. The Business Analyst is responsible for the quality of requirements and their implementation. The Project Manager doesn’t work on documentation: they can just receive the requirements from the Business Analyst and decide which ones will be included in the sprint. The Project Manager makes sure that all developers are equally assigned with tasks, no one has nothing to do or, vice versa, is overloaded. In a nutshell, the Project Manager is responsible for resources and meeting the deadlines of product development and delivery to the customer. The Business Analyst is primarily a provider of elaborated User Stories and a consultant on the project. How do I know that the Business Analyst has completed the job successfully? As we said above, the job of the Business Analyst is to ensure that the customer will receive the maximum profit with fewer product costs in the future. Then how can the performance of the Business Analyst be measured? Practitioners measure the success of their work by the following indicators: The Business Analyst has worked out a sufficient number of User Stories and joined grooming; User Stories are not returned for refinement and go to development; The testing process reveals almost no bugs; The product is released on time and with the scope agreed; Everything on the project is carefully planned and organized, and there is no team downtime; The user is satisfied; The customer gains profits. To make it clearer, let's imagine a situation where a project starts without a Business Analyst. The process is not orchestrated, and the release deadlines are missed. The quality of the documentation is poor. Everybody works as they want, hurried by the customer, and the product includes many errors. And then, into this dreadful chaos comes the Business Analyst - and debriefing begins. It turns out that the documentation should’ve been revised and improved. That’s why bugs are coming out of the woodwork: they simply were not fixed before due to inaccurate requirements. Clear planning of sprints with prioritizing requirements and functionality appears, costs are lowered, the time needed to complete tasks is reduced, and developers begin to “be friends” with other team members. And the customer is gloriously happy that the work is finally going well. Life becomes easier and for both the team and the customer. Conclusion As we have shown above, a Business Analyst is a must-have on a project, whose competencies the success of development largely depends on. The Business Analyst is able to prevent problems that would exceed the cost of keeping this specialist in the team a hundredfold. Taking into account that the activity of the Business Analyst is aimed at maximizing the profit from the product, their work will pay off with interest in the future. Andersen's team takes on tough challenges and creates unique products. Our Business Analysts provide IT consulting services, work out solutions and conduct the discovery phases for projects, while developers help to successfully implement them.