Common mistakes of a Junior Business Analyst and an approach to fixing them
If you’re starting your BA life, you can use this article as a list of practices to escape.
Being new to a sphere is hard. Especially in a sphere where you actually need help to do the first steps right. I’ve done my first steps in business analysis with no help from mentors and it resulted in a catastrophe. Let me give you a breve overview of possible junior BA mistakes and how could you overcome them.
Fear of asking more questions
I had too much fear to ask questions. I thought I can ask a dumb question, but only a question not asked can be considered a dumb one. Actually, a BA has to ask all possible questions to all possible groups of stakeholders as only it can help to understand the problem from all sides.
How to overcome it? People can think your question is stupid on many occasions. Some think a bad question is one that is too basic, not in time or communicated to the wrong person. To soften “dumbness” of a question you can explain the context and why of the question.
Accept the fact that a question should be considered silly only when it’s not asked and don’t be shy. As a BA you are to explain a problem to developers and there is no way to do it without understanding it. And to understand you have to ask questions.
Not enough meetings with devs
For some reason, developers, in general, don’t like meetings. They think it’s a waste of their time. In this case, we didn’t even ask devs if they want to participate or not. In the end, the lack of communication resulted in the fact that all sides understand each other very bad.
How to overcome it? You have to always engage your stakeholders in work on the project and in open communication. Developers are also a group of stakeholders, aren’t they?
What you can do to engage them? Just ask them to have a brief call with you. Patiently explain the problem you’re facing, note the answers, ask more questions. As a BA you don’t need to be a tech guy, but you have to understand the technical part of the solution. To do it you can study coding (but is it a good solution?) or just ask your devs to tell you how and what is being done.
Speaking about stakeholder engagement, there is no need to hide one stakeholder party from another, let them meet, let them understand each other, and later implement what would give the most value to the end customer. As a BA you can just schedule a call for all needed groups to get a common understanding.
No formal follow-ups with the client
When you speak to someone and you gain consensus on something in the BA context, you have to fix it somewhere. Period. I didn’t understand this rule, so after speaking to a client I only adjusted the tickets or communicated the change to the developers.
How could formal follow-ups help your project? If you have a project with a high amount of risks or your client is sending change requests as bugs, then you have to defend your team and company.
How to overcome it? Just note all the decisions made during a meeting and send the list to the relevant stakeholders to inform them. It can be an email or a confluence page. This can be considered a document, so this will help you to defend your team in case the client does not agree on some aspects of the developed solution.
A bad BA approach chosen
BABOK has good advice on how to choose an appropriate BA approach, but I ignored it. The project had high risks due to the type of client and client relations with the initiative dev team and the company as a whole. In this situation, I had to use a formal approach to reduce all these risks.
How to overcome it? When planning and approaching you to have to ask questions about the type of client & project, risks, and challenges in engaging stakeholders. Considering all these (and even more) factors you can choose the right BA approach and finish the project well.
No modeling done
The system was pretty complex and only one team member knew how this machine works. I had not only to become the second one but also to document it so that we could summon 3rd, 4th, and even more.
How to overcome it? What’s the best way to document a complex system? To make a model (diagram) which will give a big overview easily and fast. No one actually wants to read long texts.
Diagramming may require a big effort from a business analyst, but the result pays off when new people come or the experienced guys need to refresh their knowledge.
No knowledge base for devs and QAs
Making the best requirements architecture for the context you operate in is essential to BA. I ignored this task completely. It caused not inability for easy onboarding of new team members, but also those who have already been onboarded had no place to check if a requirement exists, whether was it implemented or not, how it works, and how can a new requirement impact already implemented features.
How to overcome it? If you have a complex system, then you won’t ever be able to remember all the functions in it. Be ready to develop the approach to document it and allocate it properly in your document storage. These documents should be accessible by the customer as well as by the team and give them the needed level of detail on functions implemented.
Conclusion
We all make mistakes. Sometimes they’re big, sometimes they’re smaller, but we have to study from these mistakes and don’t repeat them. Iterate a personal performance review to find your weak points and become better and better each day.