We use cookies to ensure you get the best experience on our website.
Accept
Accept

What is annoying in the work of a business analyst and what to do?

04 Mar 2024

Hello! My name is Viktor, and I am the Head of Business Analysis Competence Center at Vector Software.

Our work plays a significant role in software development, product creation, change and innovation, because our expertise helps make decisions and make informed choices based on data, facts, and end-user needs.

However, like any profession, the work of a business analyst is filled not only with interesting tasks and inspiring results, but also with a considerable number of challenges and difficulties.

In this article, I want to share what annoys business analysts and what to do about it.

  • Insufficient engineering and system approach to designing or implementing a software solution.

Sometimes, the development team or individual developers try to close the issue as quickly as possible and make a solution that covers the requirements in the easiest or fastest way.

Why does this annoy the business analyst?

  • In this case, the business analyst is forced to write more detailed and technical and functional requirements, taking over part of the responsibilities of the designer of the technical solution. The volume of documentation is growing, but the quality is falling. A business analyst is forced to shift the focus of his efforts to the plane of technical expertise, which is not his strong point, instead of spending more time analysing the root causes, business and user problems.
  • Hasty or insufficiently systematic software solutions, as a rule, in the future, increase the backlog of improvements and necessary changes arising from the imperfection of the implemented software solution. Such elements are often accompanied by a decrease in the level of trust in the team on the part of the customer or user. A business analyst who establishes comfortable cooperation with the business and the team is forced to come up with cunning strategies to maintain the level of trust to neutralize the negative consequences of an imperfect technical solution.

Recommendations:

  • The implementation of an engineering and systems approach to the development of software products requires time and considered actions, both on the part of the manager and each team member. However, for his part, the business analyst has a significant arsenal in achieving this goal.
    Firstly, these are communication skills: communicate expectations to the team, describe the benefits and argue for the need for engineering collaboration of the entire team. 
  • A software product must contain business value. Considering software solutions, system functionality and scenarios from the point of view of the final value for business and users allows you to focus resources in the direction of achieving a high-quality result and spend less time discussing minor technical solutions. A general recommendation is to add to the description of the technical solution a section with justification of the chosen approach, its advantages and disadvantages. If the software solution allows you to simplify the development, contributes to the implementation of new functionality or optimization of the existing one, then it will not be superfluous to communicate this in the specification.
  • The analysis of errors, the structure of the backlog of technical debt and the backlog of changes makes it possible to show the team in practice the problem of insufficient in-depth analysis or systematical decisions made by the development team.
    The general advice is to retrospectively analyse the results of the engineering decisions made and their impact on the backlog of changes, user and business feedback.
  • Non-functional requirements

Of course, non-functional requirements are part of the requirements’ hierarchy, and their collection and analysis are part of the business analysis remit. That is why there are often cases when the responsibility for collecting and documenting non-functional requirements can be delegated to business analytics.

Why does this annoy the business analyst?

  • Working with non-functional requirements is part of the competence of business analysis. However the knowledge and tools of business analysis are used by all team members at one or another stage of their work process.
    Non-functional requirements are a set of requirements from various areas of the software product and business.
    Being an expert in everything is not an easy task, sometimes impossible. In this case, the business analyst has to devote a lot of effort to communicating issues in which the business analyst often has only superficial knowledge.
  • The main focus of a business analyst, by definition, is the value of the result for the business and the user. Functional requirements are usually difficult to evaluate and prioritize in terms of impact on the quality and value of the final software solution.
    It is a way of communication with many experts, compromises and controversial needs.

Recommendations:

  • The right solution would be to enlist the support of specialized experts for each category of non-functional requirements (for example, performance, security, UI/UX). Interviewing, thorough documentation and analysis of the requirements of the expert environment allow you to create a general picture of non-functional requirements with a lower level of stress ;
  • Using pre-prepared checklists, templates and examples from similar projects will allow you to set the right canvas at the beginning.

 

  • Simultaneous combination of several project roles

Often nowadays, business analysts can be assigned non-core roles and responsibilities, or even combine two positions in one – for example, RM / BA, BA / QA. Combining roles and responsibilities in the work of a business analyst often requires a special approach and unique personal qualities.

 

Why does this annoy the business analyst?

  • Essentially, the role of a business analyst is to carefully analyse business and user needs, translate requirements into actionable ideas, and facilitate effective communication between the team and the business.
    However, the imposition of additional roles and responsibilities outside the purview of business analysis can dilute the primary focus of the business analyst, diverting attention and resources from core tasks.
    Additional responsibilities can sometimes compete with primary functions, creating chaos and ambiguity.
  • Expanding the responsibilities of a business analyst with the responsibilities of other team roles (for example, project manager, QA, etc.) can lead to overloading business analysts with non-core work, which can subsequently lead to stress, fatigue and burnout.
  • If business analysts feel that their work is suffering from the addition of additional roles and responsibilities, this can lead to a decrease in the quality of work performed, as they may be forced to complete tasks more quickly or with less attention to detail.

 

Recommendations:

  • A clear formulation of the list of responsibilities and expectations and an analysis of the available opportunities in time and means to perform new tasks will enable the business analyst to correctly plan and allocate time for work on different roles and reduce the negative consequences of frequent switching context and accompanying differences in approaches to work.
  • The work of a business analyst can be successfully combined with the duties of holding general meetings in the team: retrospective, planning, demo, daily stand-up.
  • Delegation of responsibilities for scope analysis, construction of critical development paths, analysis of team performance, and formation of weekly reports on the project may also be acceptable.

 

  • Perfectionism

In analytical and creative work, the pursuit of perfection often backfires. While meticulous attention to detail is an important part of a business analyst’s job, an obsession with perfectionism can slow progress, stifle creativity, and create unnecessary complexity.
Business analysts, who have to work on projects or products from different business domains, often have to face numerous challenges and difficulties on their way, one of which is the spectre of perfectionism, which casts a shadow of frustration and often slows down progress in the implementation of creative tasks even without especially of great complexity.

 

Why does this annoy the business analyst?

  • Perfectionism can manifest itself as a permanent search for perfect solutions. Requirements documentation, backlog processing, and other tasks are delayed because business analysts are endlessly pondering over small details, unable to tell the forest from the trees.
    This takes a large amount of mental resources, the amount of unfinished work accumulates, which in the end is very demotivating and tiring.
  • The relentless pursuit of perfection harms mental and emotional well-being. The constant pressure to meet unattainable standards feeds the cycle of stress and burnout.
    With deadlines approaching and expectations rising, business analysts often find themselves in a state of constant anxiety.
    The relentless pursuit of perfection turns from a noble pursuit into something that harms the mind, body, and spirit.
  • Perfectionism can become a barrier to meaningful dialogue and collaboration within and outside the team. Business analysts striving for perfection can find it difficult to interact with team members constructively.
    Feedback, which can be used to improve artefacts and communications, becomes a source of anxiety and fear. Perfectionism creates barriers to collaboration and impedes progress.

Recommendations:

  • An iterative and evolutionary approach to work, coupled with feedback at each stage makes it possible to reduce the level of excessive complexity.
    Highlight the most priority artefacts, following the “good enough” principle, document the main requirements and sections of the artefacts, make sure that the content of the artefacts is clear and sufficient for direct consumers, and add the necessary clarifications.
  • A business analyst is a team player who is often the main consumer of the artefacts the business analyst works on. The quality of the expected result is assessed by the team and business representatives ;
  • Monitoring and control of the time of work on the artifact combined with timely planning allows you to focus on its main and most important elements.

 

Let’s sum up

The work of a business analyst is saturated with many unexpected situations, interesting and creative tasks and constant communication with completely different people. Each project, each iteration is different in one way or another – it is a new experience, a new context.


Only a calm and confident analysis of the experience gained, openness to new knowledge and a balance in the distribution of one’s forces and internal resources will make it possible to effectively and productively provide the development of software products with artefacts of business analysis.