INTERVIEW: A substantive conversation partner. On the role of the business and systems analyst

He helps define the client’s needs, works on the specifics of the requirements of the target IT system, and acts as a liaison between the client and the developers. A business and systems analyst is a person who knows the business world and understands the client’s needs. At the same time, he is able to propose technological solutions viable for implementation. What does his participation look like in practice in the process the final result of which is to help the client achieve his goals? We discuss the role of the business and systems analyst with Marcin Dąbrowski, Head of Business Analysis at 3Soft.

Marcin, you have a lot of experience in working with the business world. What are the most common reasons why companies, despite available budgets, are reluctant to use dedicated IT solutions?

During many years of working as a business analyst, I have encountered various clients and challenges. Some clients are concerned that a dedicated IT solution will not meet their expectations, will turn out ineffective, and will exceed their budget. They also worry that the work may take longer than originally planned. In my experience, we can prevent all of these potential problems with a well-executed business and systems analysis.

What information provided by the client is crucial to you? Is there a universal template of a brief to start joint activities or is each situation highly individualized?

One should always start by learning about the business objectives and understanding the business context which has led to the decision to build a dedicated IT solution.

I often use the Business Model Canvas, which is a starter template for strategic management that helps create new business models or describe the existing ones. I complete it together with clients during workshops. In this way, I learn about the company’s model and business environment. This allows me to have a good understanding of the process to be improved or the problem to be solved.

It is also important to understand the industry well enough to become a substantive conversation partner for the client.

These are universal steps without which I cannot imagine moving on to further stages of the analysis.

What does the process of obtaining the necessary information from the client look like? Does the client simply answer the questions or is it a workshop during which both parties try to work out the best solution?

Choosing the method of obtaining requirements depends on many factors. It is crucial that the method is efficient and meets the client’s needs.

I often rely on workshops because they are an effective way to obtain requirements. Nowadays they can be held online, which makes them easy to organize. The available tools and knowledge of a wide range of techniques enable me to obtain all the necessary information and data.

Of course, I don’t limit myself solely to this formula of gathering requirements. Recently, I have used several methods simultaneously for one of our industrial clients, in addition to classic workshops, due to the large number of stakeholders in the project. They included surveys, documentation analysis, as well as observation of work at the production plant. Regardless of the method chosen, the most important thing is to be well-prepared and to carry out the analysis process correctly.

What is the outcome of the business and systems analyst’s work? What does the client get after the analysis and what are the next steps they can take?

The result of the analyst’s work should, above all, be documented. For the industrial client I mentioned before, we had prepared an analytical document that included a description of the goals and business requirements, processes, system architecture and mechanisms, as well as the necessary diagrams and models. All of these made up a complete solution design, which enabled the client to move into the implementation phase with the feeling that the prepared solution would meet their needs.

What is the analyst-client relationship like at the software implementation stage? Is it possible to make changes at that stage? If so, what are they?

At this stage I am in constant contact with the client. During the implementation, I describe the requirements in detail and confirm them with the client. I also consult regularly with the client to make sure that the software meets their expectations and is in line with their business vision.

The room for change largely depends on the cooperation model. In projects where scope and cost are fixed, the margin for change is much smaller. However, this mainly applies to small projects or changes to existing systems.

For medium and large projects, the analysis document does not contain detailed requirements, which take too long to obtain and generate the risk that a very detailed analysis will become outdated. For those projects, I recommend an agile approach to the project scope followed by an iterative and incremental implementation. For one of our recent clients from the nuclear energy industry, we used the FBSC (Fixed-Budget, Scope-Controlled) model. We determined the budget and schedule based on the understanding of the client’s business objectives, but still retained the freedom to change and adjust the scope of subsequent iterations of the system. This approach promotes faster delivery of business value and responds to a dynamically changing business environment.

Does it often happen that the expectations originally defined by the client change significantly while doing the analysis? What are the most common reasons for that?

Major changes are usually related to the client’s expectations of the system’s functional requirements, less often to business objectives. The client’s changing expectations are often the result of the work the analyst has done. The definition of business analysis according to the BABOK® Guide (A Guide to the Business Analysis Body of Knowledge®) is “[…] identifying needs and recommending solutions that provide value to stakeholders”.

By asking questions and using my experience in designing IT systems, I help clients choose the optimal path to achieve their business goals.

Our cooperation with the client consists of several stages, the first of which is the Business Discovery workshop, which I heartily recommend to anyone who is considering implementing dedicated software solutions at their company.

Marcin Dąbrowski – a graduate of the Faculty of Mechanical Engineering and Computer Science at Częstochowa University of Technology. He started his career in IT as a network and information systems administrator. Over time, he felt an increasing need to work with business. As an IT analyst, he implemented modern IT solutions in the energy industry. Since 2018, he has worked at 3Soft, first as a Business and Systems Analyst. Currently, as the Head of Business Analysis he is responsible for the entire area of business and systems analysis. Since 2019, he has been an active member of the Requirements Engineering Association. As the coordinator of the Silesia region, he is responsible for organizing meetings to spread knowledge and good practices in the field of requirements engineering and business-systems analysis. He is passionate about cooking and wine, and loves classical music. As a hobby, he is trying to learn to play the piano.