To get your stakeholders to reveal the real issues for your business analysis, you have to do a bit of hunting. Stakeholders aren’t just sitting like ducks in a row around the conference table with all the problems and answers outlined for you on a nice, neat, big master list.
Chances are that each person has a different perspective of what’s wrong and how to fix it. Or maybe they’re just telling you (or their boss) what they think you want to hear. Or perhaps they don’t even know what the real problem is or how to fix it.
To be successful in your analysis, you must go beyond just gathering up whatever information the stakeholders present to you and elicit requirements instead. Maneuvering about the human mind takes skill, finesse, and cleverness. Eliciting requirements is all about knowing how to design and ask a question.
Put the time in early! Develop questions prior to the elicitation session to make the most of it and drive out the information you need.
“What” questions
The answers to “what” questions help you build a general, big-picture framework so you can start filling in details with the other types of questions later. The answers to “what” questions provide information on the scope of the problem or a description of the problem. They get to the basics of the basics — the heart of the matter, the bottom line.
“What” questions are questions such as the following:
“What is the problem you’re attempting to solve?” Usually, businesses undertake business analysis projects to solve business problems. By understanding the problem a business is facing, you can best guide the follow-up questions to glean what the business really needs.
“What is the opportunity you’re trying to take advantage of?” Sometimes the company doesn’t actually have a problem; it just wants to take advantage of an opportunity.
“What is the information/data you need to record and store?” Businesses live on information, so they have to understand the data they need. Asking “What information do you need in order to make decisions in your daily operations?” leads to follow-up questions such as “What does order history mean? What does customer profile mean?”
“Who” questions
The answers to “who” questions help you understand not only the people but also the systems within the scope of the project. You really get a sense of who’s turning the cogs and how they all relate to each other. And the relationships that “who” questions uncover can prove to be some of the most revealing information of all.
“Who will be creating the information?” This can lead you to discover stakeholders who may not have been identified in the beginning. Follow-up questions may be “Why is she the employee who creates this information?” and “Who does she collaborate with to create it?”
“Who will be using the information?” Just knowing who creates the information is only one piece. Knowing who receives the information also helps you understand how many people are involved and how information should be communicated in the future.
This question can lead to follow-up questions such as “Who are the people in that organization?”, “What are their skill levels?”, “Who do they interact with?”, and “How is the information passed from the creator to the user?”
“Who is impacted by the solution?” When you understand the people impacted by your solution, you’re in a much better position to understand the direction and effort you need to put into the solution. If your answer is “toddlers,” you’re going to approach the solution differently than if the software is for adults and has to interface with Microsoft Office.
“Why” questions
On the surface, this question type gets you to the motivation behind the request. But it can also unearth deeply hidden information because it requires stakeholders to really be conscious of their operations.
Doesn’t everyone fall into a sort of autopilot-driven routine at work? The “why” questions flip that switch back into manual mode and force stakeholders to think about what they’re doing, which is super important for your analysis. These queries are great questions to lead you to the motivation or the reason the company is spending money pursuing this opportunity.
“Why is the company pursuing this opportunity over another?”
“Why did the company decide on purchasing that software over other available options?”
“Why are we rolling out a requirements management tool right now?” What you may really mean by this question is “Why are we buying a requirements management tool when we haven’t even defined our internal processes yet?” but phrasing it the second way may be politically volatile.
The former version addresses the same issue in a more neutral way.
“Why is the ROI (return on investment) 2 percent over 10 years for this project?”
“Why are we furloughing people with the highest intellectual capital in the company?”
“Why isn’t the company changing to keep up with the times?”
“Why” questions don’t always produce direct answers right away; you may get responses like “because that’s the way we’ve always done it” and the business analysis version of the parental standby “because I’m the parent, that’s why!” In these cases, figure out what the stakeholders don’t understand or why they don’t want to share.
