The Oxford English dictionary tells us that the term elicit is derived from Latin and originally meant to to call forth or draw out by trickery or magic. Take for example a 2013 FBI press release with the title Massachusetts Man Charged with Making Hoax Emergency Calls to Elicit SWAT Team Response. Not exactly what us business analysts usually think of when we use the term.
Spies and Counter-Spies
But the FBI does use the term in other ways that are very relevant to business analysts, and in fact it provides a free brochure called Elicitation Techniques in which it describes how spies and counter-spies discretely gather information from a variety of sources and then piece the information together into something useful. The FBI defines elicitation as the strategic use of conversation to extract information from people without giving them the feeling they are being interrogated. They provide the example of trying to plan a surprise party for someone, where you need to know his schedule, his friends’ contact information, and his food and drink preferences, but you can’t ask him directly.
The FBI provides a long list of elicitation strategies including being a good listener, starting a conversation at a high level and gradually leading it to be more specific, word repetition, mutual interest, flattery, stating assumptions that invite correction, questionnaires and surveys to get people to agree to talk with you, and so on.
The spies have long known that just asking one person a direct question may not always give you the whole truth; the real value is having multiple sources that either confirm each other, or to identify discrepancies which merit further analysis.
And the spies also know that it is essential that you ask the right people. Different people have different expertise; its not always the most senior or most experienced person who provides insight.
Sometimes, a Conversation Just isn’t Enough
Sometimes, SME’s don’t agree, and the BA encounters what are sometimes called conflicting requirements. Just asking more questions may not shed any more light on the conflict.
The very first thing to do is to verify that they are expressing a requirement that represents a need and not a solution; then be clear whether they are describing the current state or the future state. Believe it or not, sometimes when you ask a SME about their requirement, they could tell you what the current system does, or how the new process could or should be organized, and think that they are providing you with the answer you need. It can sometimes be difficult to tell the difference.
Asking the SME’s “why does it have to be that way?”, or “why is it that way?” can often differentiate between a requirement and a design; and their perspective of the current or future state.
Once you have confirmed that there really is a conflict about the requirement, consider using other elicitation techniques to provide independent corroboration, such as research (web searches, reports from expert consultants, current process documentation, statistical reports of transactions), benchmarking to learn what other organizations do, and surveys.
When Experts are the Only Source
Scientists and engineers suggest that elicitation is the process of extracting expert knowledge about some unknown quantity or quantities, and specifically use elicitation to help achieve a consensus among a group of SME’s when no one SME definitively knows the answer. Psychologists have taken it a step further and attempt to determine a probability distribution to assess the quality of the expert knowledge.
The basic idea is to replace conversation and debate (or argument) with task performance. This can reduce the influence of SME’s who tend to dominate discussions, the unwillingness to abandon publically expressed opinions, and avoid false consensus and groupthink. These techniques encourage buy-in and consensus by actively engaging the experts in the performance of the task, identifying discrepancies, and collaborating to understand the inconsistencies.
Rather than just ask questions and record their expert opinions as fact, use a structured process to allow a group of SME’s to independently apply their judgement several times, in a variety of situations, in order to identify patterns and assumptions that the individual SME’s may have difficulty recognizing on their own. For example, ask several SME’s to review case studies or perform tasks from the business domain to provide their expert opinions, and then ask them to explain why their conclusions differ. This helps to uncover tacit knowledge and hidden assumptions behind the conflicting requirements.
In the Delphi technique, SME’s individually answer a questionnaire or perform a set of tasks, and provide a justification for their answers. These explanations reveal hidden assumptions held by each expert. The assumptions are then discussed among the SME’s in a facilitated session. Some of the assumptions may be dismissed, but most will reveal characteristics about the requirements that were previously unstated. For example, in a business process, there may be decision points that must be modified to deal with situations that hadn’t been identified before; new steps may be identified which address the data quality or lack of information available to the person performing the task, and some steps or even entire flows may be eliminated. The facilitator, in our case the business analyst, uses the Delphi technique to manage the effects of group behaviour and instead allow the SME’s to collaborate to identify and describe why they do what they do.
Nominal Group Technique
In the Nominal Group Technique, each SME is asked to perform a task or to describe a solution to a problem. Each SME describes their approach to the group. The BA clusters these explanations, so that duplicates are removed. Next, each SME is asked to rank the proposed solutions as best, next best, etc. Often a secret vote is used to minimize the influence that some SME’s may have on others. You could use points to weight each of the votes, such as 5 points for “best”, 4 points for next-best, etc. The BA reveals the total points and then facilitates a discussion among the experts. If there is a clear winner, then little discussion may be required; but if there is no obvious consensus about the “best” approach, then there are likely some underlying assumptions that have not yet been identified and agreed to, and so the process is repeated. This technique often leads to a hybrid “best” approach that can be supported by all of the SME’s.
What if you are trying to discover the requirements for a product or service that has never been done before? You could develop a hypothesis about each of the conflicting requirements which could then be confirmed or rejected through an experiment. The experiment should be designed to test just the hypothesis, while minimizing the cost and risk to the organization, and the people involved in the experiment. Develop a prototype based on one SME’s perspective and test it with independent users; or build a simulation of a process and execute it hundreds of times in simulation. Sometimes a limited pilot of a new solution can identify requirements which no one could have known before it is put into real use by real people in real situations.
Ask your SME’s to observe and interpret the results with you. You might use the Nominal Group Technique to facilitate the discussions.
Okay, so we won’t usually rely on trickery or magic to elicit requirements, but it is worthwhile to recognize that SME’s find it very difficult to give us simple and straight forward answers to our questions about their requirements: their business situations are very complex, and different SME’s legitimately have very different perspectives. Use a combination of techniques to elicit information, use conflicting requirements as an opportunity to discover unstated assumptions, and apply other techniques like expert judgement and experiments to corroborate the information. And every now and then, someone may have to pull a rabbit out of a hat.
Don't forget to leave your comments below.