Blog

What you shouldn’t be as a Business Analyst

The role of a Business Analyst is very fluid; you move, you discuss, you present, you document, you set up, you relate, you anticipate, you connect, you coordinate, you fact check, you present, you discuss, you meet……. If you’re not very vigilant and sensitive to what you should and not do during these movements, you run the risk of rolling off into some domains that you shouldn’t. In fact, to put succinctly, you may needlessly be setting up yourself on pins and needles on your project. Let’s run through a few things you shouldn’t struggle to become.

Don’t struggle to fill up the space of or for the business

In any place of work, be it technology or audit or construction, as long as you operate as the Business Analyst , over time, you’ll become the most business facing member of the team (Business here means users or stakeholders in general) and by sheer expectation, you’ll become the most knowledgeable of users operations. If this happens, you might just be ‘tempted’ or ‘deceived’ to want to start pre-empting users’ requirement: you begin to create requirement unconsciously, modifying requirements and entirely jettisoning some functionalities that the users might need to perform their daily tasks. Never do that!

You’re not a skilled QA, so don’t push it.

Yes, you document business and functional requirements that are some of the significant road map and preludes to your test cases and test scenarios. The development of test cases and scenarios are most likely going to fall on your lap (not so in all cases), however, note that there are more than your eyes can see in testing, particularly when the testing revolves around a system project. Testing methodology, resource arrangement, scheduling, configuration etc. are some of the other vital component of end to end testing. The part you play at the testing phase will be meaningless without these other critical parts. So, why discomfort yourself by squeezing in into a space that has its skill set and should be left to the professionals. I advise that you operate like an Olympic athlete in sprint: stay on your track, else you’re disqualified.

You’re not a Developer, this you should know by now!

In one of my other write ups, I tried push and encourage you to ‘get out’ of what I call ‘Literature Business Analyst and transition into a system business analyst. If you have successfully transitioned- good for you, you would have acquired or be acquiring knowledge about data architecture, relationships, network design and programming/coding etc. I understand many might have transitioned into developer role. Okay, now that you have acquired some technical knowledge, never try solution users’ needs. Leave it to the developers, else you’ll acclimate to certain set of professional behaviours that would surely hinder you to effectively perform and succeed as a Business Analyst.

Yet, you’re not the Project Manager.

Again, in another write up, I stressed the importance of you wearing the cap of a project manager in some situations, yet, that you do that doesn’t entirely mean that you become a Project Manager. It sounds strange again here. Yes, I understand some of us combine the capabilities of both Business Analyst and Project Manager, while it is possible to act in both capacities at one time, where it is separated (which is a model I recommend to my clients), you should leave issue escalation, prioritization, fund management, overall project management etc. to the Project Manager. Some projects have other interlocking interfaces, some span across departments, countries and regions, some project resonate up to the level of very senior executives. Managing these interfaces require a lot of efforts and time, taking hard decisions that may conflict with your essence and role as a Business Analyst. Keep off these nuances. Stay focused as a Business Analyst and deliver superior results always.

In conclusion, while Business Analysis may provide you the opportunity to see dependencies before others, identify larger and tiny to sight underlying risks on a project, provides insight into development components and processes, it definitely does not usurp the critical space and contributions of the other expertise on the team. Be careful!

We understand more about the possible pitfalls that may be out there for business analysts. Contact us to learn more.

Comments