The role of a Business Analyst is ever changing as companies introduce similar roles, so what’s expected from a BA can vary from organization to organization. Business Analysts can be leveraged in house or on a project team for client work. In either case, they are working closely with two teams; the “Stakeholder” team, which can be a client or a department within the organization. This team works closely with the “Project” team, who is responsible for providing a solution for their client, which could be internal or external.
BA teams can work on both internal and external projects — they help bridge the gap between teams by defining requirements, doing research and analysis on the best options, and proposing solutions. Often times we are context switching regularly throughout the day, and adapting to the different types of projects and stakeholders. As a result, it’s important to be organized to make sure nothing falls through the cracks.
BA? What’d you call me?
A business analyst is a liaison who works to translate the stakeholders needs into requirements. The BA asks questions in order to understand the structure, policies, operations and objectives of the client stakeholders to architect solutions that enable the organization to achieve their goals. The intent of a BA is to take this understanding and develop project requirements to ensure the stakeholders needs are met, while also working with their internal team to drive the direction of the project. It is very much a balancing act.
That’s the nutshell version, but let’s talk about what a BA actually does to make a project successful.
So, what do you do?
It all starts with research, lots and lots of research. Good BAs take the time to understand not only the business goals, but the stakeholders and company values that are driving those objectives. The BA is also responsible for capturing the big picture including the opportunities, threats and competitive advantage to ensure the proposed solution will create the highest and longest lasting value within the organization. This phase requires a lot of questions. Get comfortable with the question “Why?”, because it’s the base of your arsenal.
Every BA may have a preference on how they elicit requirements from stakeholders and not all techniques work for all projects. Having a deep understanding of the different techniques and the client helps the BA to decide what techniques to apply to each project.
Here are some examples:
Stakeholder Interviews
Simply put, talk with your stakeholders. The intent is to understand the objective, current state and pain points of each interviewee through their eyes, as it relates to their role. Take the time to meet with a variety of people, to help obtain the big picture and identify trends across disciplines and roles. See if the interviewee is comfortable with you recording the audio, or take shorthand notes during the session and then schedule time immediately after the interview to fill out the notes with more details.
Questionnaire
Too many stakeholders and not enough time to schedule interviews with all of them? No problem. Take the questions you would have asked in the interview and ship them as a questionnaire. Google Forms are fast, easy to use, and aggregate the data for you in a short amount of time. If time permits, it’s great to start with questionnaires and then follow up with stakeholder interviews to get a bit more insight. Be mindful of who you are asking to meet with or fill out a form, and tailor it to them. Trust me, that little effort will go a long way in the relationship you’re building with them.
Observations
Observe and decipher. This seems a bit obvious, but there is an actual technique to observing a user doing their job and conducting an assessment of their environment. This allows the BA to develop a familiarity with the working style and culture of a group of stakeholders, as well as their pain points. The BA has to know what data to collect during the observation, how to use that data afterwards and what to observe. This technique is particularly helpful when an objective is to improve a process, when stakeholders have a hard time explaining what they do or when the process is highly repeatable, e.g. an opportunity to automate, etc.
Joint Application Design (JAD) Sessions
I like this one just because it’s fun to say!
“Yo, want to schedule a JAD?”
Okay, I might be alone on that, but I’m working on making it a thing. These sessions are designed to get subject matter experts (SMEs), tech specialists, and Business Analysts together to expedite develop, improve technical and functional specifications, as well as enhance user participation. This approach is particularly helpful when your stakeholders seem to have differing opinions on how something should function. The BA should have an idea of the objectives, practices and pain points before crafting a detailed agenda and conducting these sessions.
So now we have all sorts of research, what do we do with it? This is where the “A” comes in. We analyze! A good BA can take all of his or her research and translate it into something discernible for their project team. In our next blog, we’ll give you the tools needed to turn all of your research into viable requirements for your project team.
Originally published on Medium.
Comentarios