The Best Business Analysts Ask Lots of Questions
If we want to be experts and be respected like experts and be paid like experts, then we aren’t supposed to be asking questions, right?
We’re supposed to be answering questions. The weak ask the questions and the strong answer them. The weak need information and the strong are the ones with the information. The weak are the followers and the strong are the leaders. Right? Wrong!
To get better is to acknowledge areas we need help in. It’s hard to get to that point – just like that innate tendency that men have to avoid asking for directions. This isn’t really true, but it’s one of those stereotypes we’ve all heard of. Or that all teenage girls are ditzy. Ok, this one is true… I have parented more than one and my 21 year old is still operating in that mode more than her fair share of the time – made obvious twice in the last two days.
But back to business analysts and the need to ask questions and get information. The best business analysts I’ve worked with have usually asked a never ending string of questions in order to discover full and true needs for the project, the overall business processes affected, and the detailed requirements for the project. In my experience, the most business analyst’s questions revolve around these four major activities…
Making the big decisions.
Certainly, any big decisions on the project are going to require information. And how do you get that information? You acquire it – often by asking for it. You can hope that someone has it all packaged up nice and neat for you but that will never be the case. No, the excellent business analyst will need to seek out this information knowing nothing is easy to come by and nothing is going to be served up on a silver platter. Besides, the project customer is no expert. You’re going to have to drag this information out of him. Even if you have access to the right some great subject matter experts (SMEs), you’ll still have to grill many or all of them because no one customer representative will have all the information you need.
Understanding the business processes involved.
You may consider some of these customer side representatives subject matter expert s on their business processes. But the reality of it is that most are not. Most do not have the 100% overall understanding of how their business works, how all the business processes play out that will be affected by the project and how those business processes translate into the complex, detailed requirements that are needed. It’s those requirements that the business analyst must help the project manager, tech lead and tech team get to quickly so the team can move forward with the design and development without burning through all of the budget set aside for planning and design. So the business analyst is going to go to far more than just one point person on the project to get processes defined and begin the arduous process of documenting the proper, real project requirements in the detail needed.
Defining requirements.
Next, the business analyst is nearly always going to play the top dog role in truly defining the requirements of the project. The project manager has overall responsibility for scope management and all stakeholders must play a role so that the project never goes off the rails from some oversight. But in terms of leading the requirements definition effort, understanding how the tech requirements tie into the business processes, and translating that into real project requirements, that’s going to fall to the business analyst 99% of the time.
Defining the technology or tech solution.
A business analyst on the tech project is going to have to have a technical edge and a strong understanding of the technologies used in the niche he is working in. However, by no means is this individual going to be the top tech expert in everything they touch and their project touches. If they were, the dollars they could command would be outrageous. That can’t even be expected of the tech lead. What that business analyst can do, however, is ask the right questions and a lot of them to get up to speed and help get the tech team and project manager on the right track to successfully deliver on the project. In order to successfully put together the right set of requirements necessary for the project, the business analyst is going to need to know as much as possible about the technology being used to deliver the tech solution as it affects design and development of the final project solution.
Summary / call for input
The bottom line is this – if the business analyst is going to find success for the project, they must ask questions throughout the engagement. Yes, there will be times when they are going to be expected to make key decisions on their own, quickly, without the time or ability to ask many, or even any questions because the information just may not exist. There may not be any availability during the given decision window of any stakeholders or available experts who have information or answers. In these cases, they move forward without asking questions. But these are hopefully the rare occurrences on big projects and the best case scenario is realized where the business analyst does have ample time to ask the right questions and ample resources to ask those questions of and to.
Readers – what is your take on this? Are you a business analyst who asks lots of questions? Can any BA really move through the business process and requirements definition phase without almost constantly asking questions? I’ve worked side by side and very closely with some of the best business analysts around during the understanding and defining of customer business processes and I’ve helped them through the requirements definition process and it is usually almost a never ending string of questions. Hopefully this is a very organized phase when it’s an open discussion of business analyst questions and project client answers so that that the requirements document can be put together containing very complete, detailed, complex requirements for the intended solution. Questions = information = project win.