How to get started with Business Analysis?
As a business analyst, you might have worked on different projects either from the inception, or you might have joined the project in between, or it may have been a maintenance project.
The one question which we always have is – where to get started?
You might have read the arduous guides to figure it out, but it’s not only time consuming but pretty difficult to follow when you are looking for project specific skill sets. Well there are no specific rules to follow, but a quick guide to check on some of the most important aspects of business analysis skills are below:
- Know your stakeholders – it doesn’t matter what sort of project you are working on, you should always know about your stakeholders. Well, there can be many stakeholders in a project and to identify them you can create a stakeholder analysis document. This is a simple excel sheet where you can list down the name, business title/position, department, project role and any other relevant details as specific to your project. This will come in handy throughout the project lifecycle and beyond.
- Just knowing your stakeholder is not enough- Ok so now you have the list of all your stakeholder’s, you ask what’s next? Well, not all stakeholders are important or influential in a project. The key here is to identify whom to listen to? For this, you can create a stakeholder matrix mapping RASCI elements defined below against the names of stakeholders from stakeholder analysis document. Here RASCI acronym stands for
- Responsible – The one who owns the project/problem. Highly influential.
- Accountable – The one who acts as an approver. Usually signoff the work.
- Supportive – The one who is your friend. Can provide resources or help but may not be influential in a project. Kind of a helping hand.
- Consulted – The one who knows his stuff and you may require seeking his/her help often.
- Informed – The silent one, just keep him/her informed about the project.
- Deciding on elicitation techniques – There are numerous techniques for electing requirements such as brainstorming, interviews, workshops, etc. Well, this is the time you can visit your stakeholder matrix to know about the stakeholder and his/her influence on the project. For example, a VP operations guy can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your TO BE application. You may want to interview him for his point of view, concerns and thought process but might not invite him for a brainstorming or workshops sessions which may consume a lot of his time from his already busy schedule. You must check the availability, influence level, position, interest level before choosing elicitation techniques.
- Doing your homework – Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of them, if not all, improvement (aka digital transformation) projects do not start from the scratch in a way that, the business processes are already defined and followed, these are AS IS processes. For these projects, the client may have the loads of documents depicting the process/ applications designed and other artifacts of the current application(s). Analyzing these set of documents, process flows, business rules are cumulatively referred to as document analysis. As a business analyst, you should have a keen eye for details and should note down any information which is ambiguous as any assumptions here may cause dearly in the future. So be prepared before getting out with stakeholders as this will save everyone’s time, and you can decide better which stakeholder is required and what elicitation technique to use.
- Are you sure of the requirements? – Well, the chances are that you may have heard this statement before from your team members. Now assuming that you have gathered the requirements, one of the essential parts of requirement management is to analyze them. Like document analysis in the previous step, which may or may not be part of a project, this is a mandatory exercise every business analyst should follow no matter what kind of project he/she is associated with. Analyzing requirements means finding any anomalies, highlighting assumptions and constrains, decomposing requirements into functionalities, classifying the requirements and figuring out what is important and what’s not. The higher the concentration and time spend on this stage lesser will be the surprises at the end. So keep a hawks eye on it.
- It’s time to prioritize the requirements – So you have analyzed and documented the requirements, now depending on the kind of project and SDLC you follow, you may have to choose between requirements. This is mostly part of AGILE methodology where we deliver functionalities of a product/ application in an incremental fashion. Though you will have sponsors/ product owners as a business analyst, you should be aware of each requirement, its implications and need to the business. A well thought out plan on requirements delivery in phases is as crucial as the whole project. For example, considering e-commerce website example, what will be the point of delivering a functionality where users can add products to shopping basket but can’t proceed to buy, rather giving the user an option to create a wish list in one phase and delivery shopping cart and buy functionality in another makes more sense.
- Finally, can you trace the requirements back– This is required during the testing phase as well when there are differences in the said requirements and finished product. As a business analyst, you should be able to trace the requirement to its origin when required. The IT is ever-changing space, and there might come a time when someone else will access your work to define a new change. So a well-documented and traceable requirements will save both time and energy and of course the frustration which we usually witness ourselves when going through missing/unambiguous requirements from others.