13 Common Mistakes for Beginning Business Analysts

“… And the Lottery Computer, which mainly messed up something, is one of all, instead of apologizing and making excuses, not only
admitted the mistake, but even clearly proud of it.
“I’m made,” the Computer announced, “with minimal tolerances.” I am designed to perform complex and accurate operations that allow no more than
one mistake for five billion actions.
– Well, so what? The clerk asked.
– The conclusion is clear: I was programmed for an error, and I did what I was programmed for. You must remember the gentlemen that for the car
the mistake is ethical, yes, exclusively ethical. An ideal machine is impossible, and any attempt to create such a machine would be blasphemy … “

Robert Sheckley, “Coordinates of Miracles” (1968)

Hello. My name is Svyatoslav Shcherbatyuk, I work with the Dnipro office of EPAM in the role of Lead Business Analyst. I came into this profession more than four years ago from the sphere of legal support of investment projects, which I have been involved in for ten years.

Today, the question of the role of a business analyst in a project is considered in sufficient detail: it is known what qualities he should have, how he is better off building a career, what skills to develop. It is enough to use a Google search to find adequate answers.

In this article, I propose to consider the most common mistakes that most novice business analysts make. Perhaps the things that will be discussed will seem obvious to you, but believe me: this article is written on the basis of material collected in practice and such errors are regularly found in the work of even experienced business analysts.

So, in order

1. English. One of the main and most significant is insufficient attention to the level of one’s English. At interviews, one often encounters candidates with a high level of knowledge in the subject area and impressive work experience, but weak English. It should be borne in mind that most IT companies and projects are focused on foreign customers. The need for free English is determined by the place of the business analyst at the intersection of the product and the engineering team (the role and place of the VA in the Scrum team is a topic for a separate holy war) and the tasks facing it (effective communication between these teams).

A particular aspect of the language issue is professional slang, which is paid attention by employers, customers, and team members. The task of a business analyst is to establish effective communication, and this is only possible if you can speak the same language with all team members. In addition, the vast majority of professional literature and trainings are presented in English. In general, without knowledge of a foreign language, full-fledged professional development is impossible.

2. Blindly following the framework. From the issue of effective communications, another fairly serious mistake made by beginners follows – the dogmatic following of the approaches of the chosen framework. It is necessary to take into account that IT is a dynamically developing industry and the secret of success in it is the ability to adapt to rapidly changing circumstances.

You can tell the team as much as you like that “we work according to the classic Scrum / lean / Kanban”, but if the tasks and processes are unclear to her or take more time and resources than they could if using a different approach than the textbook, then there is no point in this . In that case, it would be unprofessional to say “this is a bad team, they are not following my ideal approach to the methodology incorrectly.” The task of a business analyst is to study different approaches and choose the one that will be most effective for a particular team in a particular project. I note that during my practice I have not seen a single project with absolutely “book” processes.

3. Ignoring the culture and corporate policies of the customer. Closing the topic of the importance of effective communication for a business analyst, it makes sense to mention the need to consider the culture and corporate policies of the customer when planning their work.

Despite the certain obviousness of this issue and the fact that it has already snapped many, some business analysts do not pay due attention to the cultural aspect of interaction with the customer. However, this point, combined with insufficient English proficiency, can lead to situations where a client may perceive a business analyst as “rude, not polite.” This negatively affects the work of VA in one of the most important aspects – interaction with stakeholders.

So, for example, it is better not to forget that representatives of Asian cultures can not always say “no” directly, and when working with Americans or Canadians, you should spend 5 minutes talking about the successes of their local sports team. The fact that often representatives of Eastern European, Slavic culture by representatives of Western culture are perceived as rude, I have heard repeatedly (for example, people use the “can you” instead of the milder “could you” and forget to add “please”). At one of the projects, the stakeholder directly asked why the team hated him so much. In the end, it turned out that the difficulty lies in the difference in cultures and inadequate English proficiency.

It is important to understand that for a business analyst such a mistake is unacceptable, because the probability of finding out details about which the client does not directly mention for some reason depends on the quality of his communication with the customer.

To improve customer communication skills:

• replenish the vocabulary with subtleties and synonyms;
• learn conditionals;
• Work on pronunciation
• Learn the rules for using the articles “a” and “the”.

More practical tips can be found in this article.

4. Ignoring changes in the customer’s domain. In direct project work, one of the errors may be the termination of the study of the domain domain and the specifics of the client’s business. There are situations when even experienced business analysts, having worked on the project for a long time, could not answer the question of how exactly their product works in fairly simple scenarios. Loss of interest in trends and trends in the domain area and a halt in studying the customer’s business can play a trick on the project, especially in dynamic, rapidly changing business areas. Almost all experts mention the need to constantly study and immerse themselves in the client’s business when it comes to the pros and cons of the business analytics profession.

5. Lack of proper roadmap. One of the serious difficulties may be the absence of such basic documents as vision and roadmap on the project, based on customer sales plans. Perhaps this issue is more important for large projects and belongs to the sphere of responsibilities of product managers, but a business analyst in any case can and should initiate and facilitate the process of creating such documents. If VA plans to develop in the direction of product management, this is worth considering.

As an example from my personal experience, I can cite the situation when the VA group developed a roadmap project for its further consideration and approval by the product management team. Specialists, in particular, analyzed the functionality of applications of potential competitors, the company’s sales plans for next year, plans for the development of related modules, as well as backlog stories, which for some reason were long ago rejected by product managers. Based on all this research, the roadmap was born, which customers approved.

6. There is no communication plan and stakeholder map. If you delve into the details of the work of a business analyst, the mistakes of beginners may be the lack of a communication plan and a matrix of stakeholders. You should accustom the customer to hold regular meetings, and yourself – in advance to prepare a list of issues for discussion. Frequent cancellation of calls due to lack of topics or lack of constructive dialogue may lead to the fact that stakeholders simply do not come to a seemingly planned meeting at the most crucial moment. At a key moment, he may not seem to them quite important and urgent.

In planning communication it is important to consider not only the essence of the issue, but also how it is formulated. It often happens that the client’s response also depends on the question. This is extremely important when a business analyst, as a representative of the executing team, needs to defend the decisions of the engineering team, in particular during user acceptance testing and delivery of work to the customer. To build a working matrix of influence and interest, we can distribute stakeholders in four quadrants. A good practical example can be found in this article on dou.ua.

7. Arrangements are not fixed. In continuation, one can note such a mistake as the absence of meeting notes compiled from the results of communication with stakeholders. Writing meeting notes is an excellent form of team defense, especially on dynamic projects with great mobility of managers.

I had to deal with situations when, after a while, the customer either forgot about the agreements reached, or in connection with the change of the product team such agreements were lost, and we had to convince the customer that certain changes, for example, in the release plan, were not a miscalculation, but a real deal.

8. Lack of visibility. It is worth noting the format of daily stand-ups. It is extremely important for the customer to have a sufficient level of visibility, to know where and how efficiently his money was spent. Beginning business analysts (although often not only them) do not always manage to briefly and informatively explain to the customer what work has been done.

Remember that the client will not like to know that, for example, all of the last week one of the team members was in the blocker and did nothing. I met situations when a client, on the argument that someone was blocked by something, asked: “And what did you personally do to overcome the blocker / what did you do while you were blocked?”. Use the time when you are in the blocker to improve existing processes on the project. Fortunately, there is plenty of such work (especially on new projects). And when you tell the customer about completed tasks, proceed from a proactive attitude, think about what counter issues you can anticipate.

9. Too much time is spent on parts. As a mistake for beginners, one can emphasize excessive focus on the details of the ticket and / or the intricacies of implementation in its description. On long-term projects, it is necessary to take into account that the implementation details may change with the transition to a new technology, while the client’s business will remain the same. Incorrectly accepted acceptance criteria with many implementation details (for example, describing specific methods or request / response APIs) will result in the product backlog having to be rewritten.

Otherwise, from the point of view of regression testing, the actual behavior of the system will differ from the existing requirements: it is technically necessary to start a bug ticket, the backlog becomes “outdated” (that is, the description of the state of the system becomes irrelevant). At the same time, there are no formal reasons for rewriting requirements if the client’s business processes have not changed.

10. You do not have a vision for the whole project. Also a typical mistake for large, long-term projects may be a lack of understanding of the “big picture”, links with other elements of the ecosystem, and a lack of “helicopter view”.

Understanding the connections of your module with others and knowing how a connected system develops, allows you to correctly and timely develop your own product, avoiding “dumping the details of implementation.” In addition, this way you can significantly improve the level of writing requirements. In such cases contextual compilation helps a lot. charts.

11. You go from the opposite. Associated with the previous one is the mistake of writing requirements “from the opposite” – that the system should not do. The result is a backlog of requirements, from which it is clear what the system will not do, but it is not clear what it will do. This may be due to the fact that the focus on the client’s business is lost. It must be remembered that VA thinks first of all directly about what the system does to address the business needs of the client.

12. Incorrect assessment. But the most common mistake that no novice business analyst can avoid is underestimating or overestimating the scope of the project’s tasks, as well as their professional skills. These are two extremes of the same phenomenon, which naturally arises from a lack of experience and understanding of the actual level of one’s skills.

Perhaps the most effective advice would be to not be afraid of anything, but also not to vouch on behalf of the team for some time and work in front of the customer / stakeholders. It is step-by-step to carry out all the actions that are expected from a new business analytics project. Do not forget that the same BABoK contains all the action plan you need. It’s normal that at the beginning of the project nothing is clear.

Remember that the main tool of business intelligence is communication. Even if nothing is known, identifying stakeholders is a good start to find out the project’s goal, the customer’s business and draw up initial context and workflow diagrams that will give answers to all questions of the project. And more experienced colleagues who have worked with this client or project for longer will help you to avoid creating incorrect customer expectations from the product.

13. Fear of error. He paralyzes and, instead of starting to act and adjusting the course of the project, the novice business analyst begins to “prepare for action” for a long time: carefully write letters to the customer, focus on describing edge case scenarios, unlikely workflows, which, at the first stages of the project, generally neglected. It’s okay to make mistakes: both Agile and Scrum are about making mistakes quickly and reacting to errors just as quickly.

I wish all newcomers to VA not to be afraid of mistakes and to boldly move forward. Good luck