Today, the question of the role of a business analyst in projects has been considered insufficient detail: it is known what qualities he should possess, how best to build a career, what skills to develop. It is enough to use Google to find adequate answers.
13 Common Business Analysts' Mistakes.
In this article, we propose to consider the most common mistakes that junior business analysts make. Perhaps the things that will be discussed will seem obvious to you, but believe us: 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, let’s go:)
1. English language.
If team members did not have to work while in different places, they did not need to use the same tools. But now there is such a need. This is especially true for communication tools.
Determine what exactly you will use for video conferencing. Stay tuned for any one messaging tool. Agree on what you will use to share documents and review.
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 BA 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 training are presented in English. In general, without knowledge of a foreign language, full-fledged professional development is impossible.
2. Following the framework blindly.
From the issue of effective communications, another rather serious mistake follows - a dogmatic adherence to 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 them 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. Note that during our practice we 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 BA 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 directly say “no”, and when working with Americans or Canadians, it is worthwhile to spend 5 minutes talking about the successes of their local sports team.
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 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 in the domain area and a halt in the study of 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 BA plans to develop in the direction of product management, this is worth considering.
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 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.
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.
We 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. 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 details.
Excessive focus on the details of the ticket and / or the intricacies of implementation in its description is another mistake. 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 prepared 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 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 of 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."
11. You go from the opposite.
Connected to 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 BA 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 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 plans 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 mistakes.
Sometimes business analyst 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.
We wish all of BA not to be afraid of mistakes and move forward boldly. Good luck!