Where to start as a business analyst
One of the biggest questions you might have is where to start as a business analyst?! You’ve got a new project, a new role or just the opportunity to try out some business analysis in your current job. But where do you go from there? What are some of the steps you can follow to make sure you start strong?
As business analysis can vary based on your organisation, it can be hard to know what others are expecting from you. By following the steps below you cover all bases and help set expectations with your key stakeholders. You will know where to start as a business analyst in no time!
Step 1: Analyse what is going on
As you are an analyst, use those skills! There is nothing worse than someone joining a team and trying to run before they can walk. It’s usually rare for a business analyst to start right at the beginning of a project where you can shape all of the planning. That means you often join in flight and need to get up to speed before you start doing work.
No matter where the project is, try and answer the following questions before diving into taking action:
- What is the vision of the project? What problem are they trying to solve?
- Where is the funding from the project coming from? What is that funding trying to solve?
- Who are the most important stakeholder and what do they care about the most?
- Who are the end users? How have they been engaged with?
- If there is a product already partly created then use it! See where it already has features and what it might be missing.
Step 2: Consider the benefits
Benefits come in all shapes and sizes. Benefits for the organisation, project, stakeholders even project team! The key thing to consider when you need to decide where to start is the outcome you provide.
There is no point in conducting analysis which doesn’t ultimately have an outcome that leads to a benefit.
For example, a textbook might tell you that creating a process map is one of the right steps to take. But, if you are in an organisation where processes aren’t used then it’s not where you should start. Look at the different outputs available and see which aligns best with the benefits you’ve identified.
Step 3: Get to the end user
Hopefully at this point you’ve identified your end user. Now it’s time to learn more about them! Especially if you are coming in a organisation for the first time such as as a consultant or a contractor, then you need to spend some time getting your knowledge up to speed. Even if you have previously worked in an organisation in a similar sector, it is guaranteed that there will be some significant differences.
As soon as you get onboard ask for some time with your end user. For end users which are the public this could be listening into calls with customer service, watching some customer interviews or looking at feedback online. For end users who are internal to the organisation then get some time to shadow them, sit and watch any form of operations and ask to sit in on their meetings. Anything you can do to get yourself more familiar with your users and what they might want.
Step 4: Prepare some options
By this point, you’ve now done your homework! But before diving into weeks of work to get to an output, the best place to start is by providing some options. If you create a small amount of ideas then you can begin to see what will be used within your team. For example, if you’re working closely with a development team they likely want to see something different than if you’re reporting to a product owner.
I suggest creating an example of some outputs, presenting them to your stakeholders and see what they think is best. You can then put the rest in your backlog and pick them up when needed. Consider trying:
- Requirements. This could range from creating some if the project don’t have them, trying them in a different form or rearranging them to make more sense. Often requirements aren’t grouped in a way which makes sense to the user. You could even suggest something like user story mapping or creating a product roadmap.
- Processes. These could be in the form of BPMN process maps or simply mocked up in a powerpoint slide. This should cover how the user works and interacts with the business.
- User journeys. If the org doesn’t currently know their user, then try documenting it! This could help to feed into requirements or processes.
- Service design. This could take the form of looking wider at the project. You could create a vision, blueprint or high level views of your product.
- Scope discovery. If there are lots of areas of uncertainty on your project, then the best place to start might be by trying to log and answer some of those design questions.
If you are starting at the beginning of a project, then it’s recommended you begin with a discovery phase. The outputs of the discovery phase look very similar to the above. However, they will be from scratch and usually at a higher level.
One of the big errors I often see in new business analysts is keeping their outputs to themselves until they are finished and then doing a big reveal. Whilst that can feel satisfying, it doesn’t give you the opportunity to change as you go.
Whichever of the options you choose to start first, make sure you show the end product to your stakeholders often and seek feedback. All the agile principles which apply to developers should also apply to your work too!
What next – where to start as a business analyst
It can be hard to get started as a business analyst but by following these 5 steps you are setting yourself up for success. Get in there and give it a go! If you want to learn more then consider also covering our ‘what is business analysis?‘ and ‘10 tools for remote business analysis‘ to help expand your toolkit.
What do you think about where to start as a business analyst? Comment below!