Perhaps this lack of knowledge will not hurt you now, but in the end it is what you don’t know now that ends up causing the problems. And thus the Mystique of the Right Question arises: we need that Right Question to identify the information we don’t know before it causes problems.
First, let’s look at the big picture of interrogation. Assuming that the reason for asking questions is to get information, usually information we don’t know, we can start by dividing the universe of information into the information we know and the information that we don’t know. The apparent goal of asking questions then is to increase the amount of information we know. A successful question, the Right Question, is one which moves the information from the realm of what we know we don’t know into the domain of what we do know. This matrix helps illustrate the process.
In other words:
What you know you know are the facts: the information you have already received and verified. We don’t generally ask questions about the information we know except to gain confirmation. A confirmation question in general might be considered a Right Question. When information is confirmed, the answer is valuable and when the answer does not confirm what you already know (or think you know) the information is equally as valuable if not more so. (The issue in asking for confirmation is in avoiding the Confirmation Bias. We’ll talk about that in the next segment.)
What you know you don’t know are the questions: questions that will give you the information to turn what you don’t know into what you know. To a degree, any question you ask here that produces an understandable answer can be considered a Right Question.
What you don’t know that you know is experience: the knowledge that you have that is inherent based on what you learned previously and is now embedded in your memory or subconscious. We don’t generally ask questions in this category because we simply are not aware of the questions to ask, and the responders don’t answer the questions with this level of detail because their experience is second nature and automatic. However, some questions you ask result in an answer that triggers your previous experience and that experience will help you evaluate the applicability and veracity of the answer. In this case we might consider such a question as a Right Question.
What you don’t know that you don’t know are assumptions. You might think you know, but the knowledge is not actually based on facts. In some cases you think something is a fact because someone gave you the information, but the information they gave you was based on their assumption and you are not aware of it. Questions are not asked in this situation because we are assuming that the information we don’t know we don’t know is in fact information that we do know and therefore, facts. We believe that we are in the first quadrant, when we are not. Questions that clarify and disabuse us of our erroneous assumptions are definitely Right Questions.
This last category is where many business analysts feel they didn’t ask the right questions because that information which turned out to be wrong or misleading was incorporated into the product and ended up causing problems in the end.
Getting More Information
One of the obstacles to asking the Right Question is a lack of planning. Most business analysts do prepare some form of question to ask the person they are interviewing or to throw on the table during an information gathering session. However, the questions usually are rote, and determined by the responder rather than the business analyst. In other words, we decide WHO we are going to talk to and then decide WHAT we are going to ask them. This is backwards if we are indeed interested in asking the Right Question.
When you focus on getting the right answers rather than trying to figure out what the right question is to ask, the questions occur by themselves, almost magically. But first you have to define what will be the right answers. You may even find that you can get the right answers without even asking a question.
You might throw a wide net and just ask any somewhat relevant question and hope that the answers will steer you in the right direction, or you can determine in advance what information you need to know to solve the problem and ask specific questions designed to get you that information.
The typical approach for the business analyst in the information gathering, or elicitation, phase might be as follows:
You get the assignment to solve a problem. You meet with the problem owner, sponsor, customer or whoever wants the problem solved or is paying for it. That person gives you a briefing about the issues and suggests you talk to several people and directs you to them. You dutifully call and make appointments with the several people, or you have a meeting with them. You may prepare some questions ahead of time, perhaps mentally. You go into the meeting expecting them to tell you all about what they want, what the problems are and what they want you to do about it, so preparing a list of questions seems a waste of time and effort, because after all you were directed to these people because they presumably have the answers.. The right questions in this case might fall into the category of “what do you need?” Or “what do you want?” 
If, in fact, this is an appropriate way to identify or solve problems, then there is no concern about asking the “right” question. Any question will do that gets the designated responder to talk. And the business analyst need just record the answers accurately. However, as many of you realize, the person you have been told to talk to may not actually know the situation, much less the answers, probably has not spent any time formally defining the situation or the solution, maybe distracted during the conversation, and at best will give you their one solution. Most importantly, from the business analyst’s perspective, there is no analysis of response if we assume that the responder has all the answers regardless of our questions.
To ask the right questions business analyst has to take control of the entire elicitation or investigation process, and seek the information that the business analyst needs and not settle for the information defined by someone else.
Plan to ask the Right Questions
You can increase the probability that you will ask the right questions (that is, get the right answers) by defining an information gathering plan
Reporters, investigators, journalists, authors of nonfiction books, and even those professional interviewers who bring celebrities to tears with their pointed questions, all start with a plan to gather the information to achieve their respective objectives: a news story, the guilty perpetrator, background for their book, or that specific question or set of questions that will generate a response that will increase ratings.
It makes sense that if you want to be sure to ask the right question to plan to ask the right question.
The information gathering plan, and informal document maintained by the business analyst for the business analyst (or team of business analysts) consists of four parts, which can be created in a matter of minutes at the beginning of elicitation phase. The four parts are
- What information do you need to understand the problem or the problem domain?
- Where are you going to get that information? Where is it most likely located and/or who might have it?
- How are you going to acquire the information, by what means?
- In what order are you going to collect the information?
The information gathering plan starts by listing what we need to know to achieve our objective: a list of questions and categories of information that, when taken together, will provide the right answers and pretty much guarantee that you ask the Right Questions.
Note that it is not a matter of defining the specific questions were going to ask, and agonizing over which ones are right. It is more a matter of creating a frame within which you can conduct your elicitation. You want to make it easier to ask the Right Question.
This brings us back to the original premise that it is not question that is “right”, but information produced by the question that is “right”.
Below is an example of part of an information gathering plan for an accounts payable system. Since the project involves streamlining the data flow for Accounts Payable to speed up the overall process, the initial focus is on the data. So the first people we want to speak to are the Accounts Payable manager, and the purchasing manager. We decide to have an interview with at least one of these two stakeholders. This will give us a general overview of the process from a strategic perspective, as well as defining any constraints associated with the data flow. Then we want to get more specific and look at the content of the current tables used by the Accounts Payable system. We can review the data dictionary for the Accounts Payable database and likely talk to the database administrator to clear up any questions we might have. This plan helps us organize our information gathering process and increase the chances that you will ask the right questions. 
|The layout of the current vendor tables||
|What does the overall A/P voucher process look like||
Accounts Payable Policies and procedures manual
Charley and/or member of voucher entry team
|What is the process to do vendor entry||Vendor entry clerk||Observation & Interview||3|
What is the data that goes into computing the payment terms for vendors
|Accounts Payable manager
The Information gathering session
How do you know that your interview or information gathering session was successful?
Do you feel it was successful because there was a lot of interaction? Was it successful because you ended on time? Was it successful because you got answers to all your questions? Is it because you asked the Right Question? How do you gauge success in elicitation?
I submit that the measure of success in any information gathering session is whether you achieved your objective in that session. You have to know what you wish to accomplish in each and every information gathering session. Setting clear objectives for gathering information increases the chances that the session will generate the information you are seeking to define the problem or solution, and to ask better questions.
Identifying the objective for each information gathering session is fairly simple if you have an information gathering plan. The topic or question on the plan is the objective for the individual information gathering session. For example, referring back to the information gathering plan table, we can set as our objective for the first interview. We have with the Accounts Payable manager to determine what data goes into computing payment terms for vendors. We will plan our interview with questions that will generate answers that will achieve our objective. When we walk out of the interview with an understanding of the data necessary to compute vendor payment terms, we can deem our interview a success. And we will know we asked the Right Questions.
There is more to asking the Right Question, though. We can know what we want to ask but then fumble the question during the information gathering session. In many cases the question “How do I ask the Right Question?” is not about choosing the Right Question to ask, but in How to ask it to ensure getting the Right Answer. That is the topic of the next installment.
Don't forget to leave your comments below.
 Blais, Business Analysis: Best Practices for Success, John Wiley, 2011