Senior business analyst with a strong background in the finance and banking industries. Besides, Stanislav is an ISTQB-certified QA engineer and an expert in the Agile methodology. His role implies close collaboration with clients in gathering project requirements and translating them to the dev teams.
How do you usually understand that your business needs to reduce operational costs or expand to the new market? Probably, you have some intuition about where to go. But in most cases, you rely on comprehensive business analysis. It is the most accurate way to discover what you need and how to get that. Here you will learn how business analysis impacts the outcomes of software development projects.
Below, DICEUS’s senior business analyst, Stanislav Nesterov, explains how business analysis works, why it is crucial, and how it impacts the project outcomes.
Expert opinion: Business analysis role in software project
What is the role of business analysis, and how does it start?
Business analysis has several formal definitions of what it does. There are a few schools and approaches to defining business analysis, for example, PMI and BABOK. They describe various BA stages, strategies, tools. All these definitions and guides are right. However, the most important thing about BA, in my opinion, is where it begins — business analysis and the project itself. The difference between the business value and the project value is in asking the question “Why?”.
The “Why” question should be articulated multiple times to understand why a particular idea is being realized, i.e., what its goal is and how to formalize it. Business analysts and clients should understand the goal in the same way.
What is the “Why” question?
Any project is a change. It’s a kind of beacon that should stand and be equally clear for all. By understanding why the change is initiated, we can move further to evaluate all the next steps. The answer to the “why” question is important for both a customer and a development team. It is essential for those people who implement the changes and for those who test the quality of what is being done. Within the project execution, the “why” question is kept in mind.
When the customer gets the final product, he validates it according to other criteria. Initially, when we are shaping the vision of what is needed, we need to answer the “why” question. It helps us measure the changes which may happen within the project and find common ground with the client. That is where it all begins.
What are the next questions you have to answer throughout business analysis?
The next question we ask is “how” — “How are we going to do this?”. Based on the answer to the “why” question, we search for and offer the technology and technical solutions, a set of functionalities that should be appropriately formalized. Both sides should understand these functionalities in the same way: what they need, what they want, and what is expected to be supplied.
There are several stages of business analysis. The first is high-level requirements. They are basic requirements that describe the product in general. It allows us to communicate and describe what we want to get and by what means we will reach it. There is a statement that says: “If you have any idea, try to articulate it. Once you talk it loud, you will better understand what you want.” We practice similar things during business analysis: why and how. We talk about these things with the client for them to understand what they really need and how to gain that.
When we say that we communicate the requirements, it doesn’t mean that we merely talk — this means the analysis of various documents, discussions, tools.
Business analysts know how to ask questions differently in different contexts to get the same answer. It helps avoid ambiguity within the project execution. Do you agree?
Absolutely. It’s very important to ask the question correctly to ensure that both an analyst and a client understand things in the same way. The next important thing is to formalize the answers. To ask questions and get answers is one side of the coin. The other side is to appropriately formalize them so that people who will use this information could understand it as explicitly as possible.
What happens next?
Once we get high-level requirements scope and formalized answers, we can offer a set of technology solutions, visualization. So, we can evaluate how complex and resource-consuming the project is. The important thing here is to find the balance between the two resources — time and money.
At this stage, formalization and high-level estimation are things that help move forward, identify which basic components the project is composed, how they are related to each other, how many resources they consume, and how interchangeable they are. The basic sequence of requirements realization allows us to further estimate low-level tasks and jobs: what the client would like to get first, what functionalities may be realized, when, and what resources are needed. The feedback we get is critical — it is key to success. The client understands clearly what he can get, how, when, how many resources are needed, if he can afford all that at once, or there are any limits and risks.
In case there is a lack of resources or time to implement all the functionalities the client wants, it’s possible to choose the main one and start with it.
What are the deliverables of business analysis? What does the client get?
We discuss the deliverables with the client beforehand. Usually, our customers get a set of functional and non-functional requirements that make up the project’s basis. Often, we gather these requirements after the high-level analysis stage. If the project implies UI/UX design, we provide this, as well. Architecture documentation is developed by the development team.
The deliverables of BA are documents that allow us to further evaluate the project more accurately. Detailed low-level requirements help to re-evaluate the initial estimations. In some cases, it may turn out that the project requires fewer or more resources. That’s because we analyze all the project components in detail, their connections. And if we’ve got more components, they require more skills and efforts to be realized. Thus, the estimation becomes more accurate.
The client can agree with the offered set of functionalities and terms, priorities. At this stage, we can say what can be seamlessly done, what can be put on hold for further development, and what requirements should come together. The BA stage allows us to plan the supply and realization of the project.
Why is the process of requirements gathering crucial?
They serve the guideline for developers. The project manager can use this documentation to agree with the client on the sequence and terms of functionalities release. Depending on the development model, Waterfall or Agile, the project schedule can be set up. The client can also plan and control this process. Within the development, the functionalities are also checked and tested; that’s why well-developed requirements and agreed schedules are integral to the testing team.
QA engineers also prepare plans for testing, tools to check the functionalities. They evaluate how resource-consuming this check-out will be. If the client tests requirements on his side, he also uses BA documentation. When something goes wrong, it’s crucial to allocate time for errors rework and ensure that initial requirements are aligned with what the client has got. In case some conflicts happen, well-developed requirements allow us to smoothly resolve these issues.
How to check whether the client got what he expected?
The project’s vision or values may change once the idea is realized and launched as a live product. Within some time, the answer to the “why” question can also change. It is known that any project may be initiated by a problem or opportunity that the client would like to seize. However, within the project execution, some of the opportunities or problems may become irrelevant.
The question that arises in such cases — Does it make sense to pay for irrelevant things? Usually, if the project has proceeded not far, we can evaluate if it’s possible to give up these unnecessary elements. It’s the right moment to stop and see what has been done and re-evaluate the functionalities.
So, when such moments happen, you conduct business analysis once again?
Surely, we analyze both new functionalities and their impact on the existing functionalities. In fact, any business analysis works according to three points: what we have for today, what we want to get, and how to bridge the gap. When it comes to changes, the starting point is when this decision was taken. We can analyze how these new requirements are aligned with the released ones.
Who is usually involved in the estimation process?
Business analysis involves not only analysts but also the development and QA team members. If the project requires UI/UX, designers are involved, as well. So, in case of positive decision about the project, all the people to be engaged will participate in the estimation process. This mutual estimation becomes a subject for decision and foundation for the client to make the decision. Within this discussion, it may turn out that some functionality is too expensive for the client, and he can reject it or postpone its implementation.
What kind of tools and techniques do you use for business analysis?
It all depends on the project. We see what we get in the end — a formalized set of requirements. The main question here is how to appropriately formalize those requirements. It depends on the project itself, its complexity, its concept, risks, goals. For a complex project that is close to engineering projects, we often use tables (matrixes) & diagrams. I had experience working with multi-lingual teams that were located in different countries. English was the primary language of communication. Because of the project’s complexity, we had a rule — less text and more tables and diagrams. This helped us avoid misunderstanding and ambiguity.
Summarizing Stanislav’s words, business analysis’s primary goal is to help customers understand their needs and wants more clearly and answer the “why” question. BA impacts project outcomes. Firstly, it allows us to gather requirements to the fullest extent possible. Secondly, it is the best way to document requirements. Ultimately, it eliminates low requirements stability within the project execution.
Guaranteed software project success with a free 30-minute strategy session!