Are you starting a business analyst job but don’t know where to start? It can be overwhelming at the beginning. Learn some tips on how to get started in this article.
Aim Is To Gather Requirements
A good way to start is to remember what the role is for. The role of a business analyst is to gather requirements from other people in the company for a particular solution, and document them in a way that is helpful to the IT team and the business users.
This is the aim of a business analyst. So, generally, your first step should be starting to gather requirements.
But what if you don’t know how? What if you don’t know what to look for, or who to speak to?
Get The First Steps From Your Manager
Your manager can be a good place to start if you’re not sure where to begin your role as a business analyst.
They should be able to give you some direction on your role. Try to speak to them and find out:
- What the project is called (sometimes you’re not even told this)
- What the purpose of the project is
- Who are the key stakeholders (the main people involved)
- What do they expect from you as an outcome (document, user stories, etc)
- What they think the next steps are
The key stakeholders are important here, as it will determine who you need to speak to about this project. Try to write down their names and details, if you can. You may also be able to look up their phone numbers in the company address book or contact list.
Prepare A Document
The next thing that I would suggest is to prepare some kind of document for your work here.
This could be in any format you like – it doesn’t need to be the document that you use for the project. It can be a notepad file, a Word document, Excel file or something else. I recommend having it on your computer, rather than writing it down, so you can organise it and search it easier.
Personally, I use OneNote, but that’s just my preference.
This would be used for all of your notes that you take for the project. You don’t need to deliver it or provide it as an official document for the project if you don’t want to. You could use this document as your rough notes file, and then translate that into whatever kind of documentation is needed.
I suggest making this document as you have all of the notes for the project in one place. When you’re a couple of months into the role and need to remember what someone said about a certain topic, you can go back to your notes and find out.
Contact Those You Need To Speak To
After speaking to your manager, you would have hopefully got the name of someone to speak to. Whether you got the name of one person, or five, it’s a start.
You can go and contact them to find out more about the project. Send them an email, give them a call, or go around and see them if they’re in the same building.
If you’ve only got the details of one person from your manager, that’s OK. This person would know about the project or work that needs to be done. They can also provide some information on who else you can talk to.
Write down what they say, the things that need to be done, what’s important to the project, and what needs to be done next. You can always come back to them and clarify some points, but it’s better to write it all down first. Don’t worry about going too slowly – the person you’re speaking to knows you’re new to the role or the project.
Organise Your Notes
Now that you’ve spoken to some people and got some idea of the project, you’ve probably got some idea of what needs to be done. You’ve also probably got a heap of notes.
It’s now time to organise them. You should try to translate them into whatever format you need them for your project. This could be a Business Requirements Document, or user stories, or a design document, or something else.
If your notes are detailed enough, it should be all you need. However, that’s not always the case. You can still go back and clarify some points with those people you spoke to. It’s commonly done later in the requirements gathering phase, as you get more detailed into the requirements and your understanding improves. You then come up with some “what if” questions and find gaps in the requirements.