Getting started with Business Analysis

As a business analyst you will work on different projects either from the inception, or you may join a project in that is in progress, it may even be an update project.

The question we always have is, how or where do I go to get started?

You may have read many guides or courses to find out. It’s normally time consuming and pretty difficult to follow what you are looking for in specific project skill sets. Well there are a lot of specific rules to follow, so a quick check list may help to narrow down some of the most important business analysis skill sets are listed below:

1. Get to know your stakeholders – no matter what sort of project you are going to be working on, you have to know all about your stakeholders. There are normally many stakeholders in a project and to identify them you have to create a stakeholder analysis document. This is normally an excel worksheet or a plain word document somewhere that you can list down the name, title or position, their department, role in the project and any other data that could be related to the project. This will essential and handy throughout the project lifecycle and beyond.
2. Knowing your stakeholders may not be enough – You have created the list of all relevant stakeholder’s. So now what comes next? Not all stakeholders carry the same importance or or are influential to the project. The key here is to identify which ones to listen to? The RASCI mapping matrix can be used to evaluate each stake holder element that we have defined in the description below against each of the stakeholders from stakeholder analysis document. The RASCI acronym stands for
   • Responsible – is a person who drives the project and the team to achieve the intended goal. Holding that role, a person will be in charge of making an important decision, overcoming blockers, leading the team to do the right thing, and deciding what NOT to do. Responsibility can be shared but cannot be passed to another person. 
   • Accountable or Approver – The Approver will contribute ideas, knowledge and anything else that can help the Responsible and the team make the right decision and achieve the goal. In rare cases, an Approver can jump into the critical part of work.
   • Supportive – This role supports a Responsible in project implementation/delivery. People holding this role can be involved to varying degrees.
   • Consulted – are usually subject matter experts.
   • Informed – An Informed will want a Responsible to provide them with updates on the progress of the project.
3. An excel chart is shown below

1. Deciding on what elicitation techniques to use – There are many techniques for eliciting requirements such as brainstorming, interviews, workshops, prototyping and many more. Your stakeholder matrix is a place to start to see where the stakeholders influence is in relation to the project. The VP operations role can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your project. You may want to interview him for his point of view, concerns and thought processes. Brainstorming and workshops sessions consume a lot of his time and inviting this type of role to one may not give the required results. You need check the availability, influence level, position, interest level before choosing elicitation techniques for the different types of requirements.
2. Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of them, if not all, improvement projects do not start from the beginning, as the business processes are already defined and need to be followed. For this type of project, the client should have project plan that started the first phase and closing out documents laying out the process of the applications design and operation manual of the current system(s). Analyzing these documents, process flows, business rules are commonly referred to as document analysis (elicitation). As a business analyst, you need to have a keen eye for detail and should note down any information which is ambiguous as any assumptions here may cause issues in the future. 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.
3. Are you sure that you have all of the requirements? – Chances are that you have heard the statement before. Once you have gathered the requirements, the essential part of requirement management is to analyze them. The document analysis in the previous step, will give you many of the current requirements which may or may not be part of a project, this is an important task that every business analyst has to perform no matter what kind of project he/she is working on. Analyzing requirements means finding any anomalies and grouping similar requirements together, highlighting assumptions and constrains, breaking requirements down into functions, classifying the requirements and working out what is important and what’s not. The more quality time spend on this stage will lessen the surprises at the end.
4. Prioritize the requirements – Once the analysis and documentation of the requirements are completed. Based on the kind of project and the Software Development Life Cycle (SDLC) the company follows, you may have to decide between requirements. The AGILE methodology delivers functionalities of a product/ application in an incremental fashion. Sponsors/ product owners may act as a business analyst, you need to 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.
5. As the BA can you trace the requirements back to the functionality – 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 their function to verify that it meets the requirement. IT is an ever-changing space, and there will come a time when someone else will need to access your work to define a new change. 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.