Being effective at interviewing is key to gathering requirements effectively. We suggest six tips to make the interviewing process more effective and efficient.
To be successful at interviewing subject matter experts at gathering requirements, we have to first understand how to interview our experts. This understanding allows us to define our approach, plan, and follow-up after the interview. Having a good framework for the interview is neccessary, but not sufficient. We also need to be good listeners. Being a good listener encourages our interviewee to answer our questions more comfortably and openly.
But to be truly effective, we need to do more than that.
Why This Is Hard
One of the business analysts on my team and I were reviewing actual performance, specifically time spent on-task versus time estimated for gathering and documenting requirements. We found that the time spent in subject matter expert (SME) interviews was more than double the original estimates. We found that repeated interviews and iterations were required to get a reasonable documentation of the process. We reviewed the documents and agreed that the level of detail was roughly what we desired, and that the problem was in having too many iterations.
We found that the extra iterations were needed because
- Systemic clarifications were required – the initial drafts bore little resemblence to the final draft.
- Areas of business process were missing – initial process documentation only showed the most common cases.
- Generalizations and vague statements peppered early drafts – ambiguous and incomplete statements were taken at face value initially and refined later.
The good news is that we got the desired documents, at the desired quality level. The bad news is that it took twice as long as it could have taken. The SME for this area of requirements gathering knew the subject very well. We discovered that we were struggling to get the data from the SME efficiently. We discussed half a dozen ways to improve the analyst’s interviewing process to address these challenges.
Six Tips To Double Effectiveness
- Use Absolute Statements. This is a modification of an active listening technique. When the SME says “We generally follow up X with Y”, respond with “OK, so you always follow X with Y.” This helps when working with a SME that doesn’t use precise language. One source of iteration is “well, I forgot to tell you about this exception.” The best SMEs can usually do their job in their sleep. And that is great, except that it makes it easy for them to forget to tell us important stuff. Experts can quickly deal with exceptions when doing the work, but often struggle to prepare others for the exceptions. “Always” becomes a magic word – the expert immediately knows that always is wrong, and won’t hesitate to tell you.
- Not The Opposite. Twist the SME’s words around. When the SME says “We always X if Y”, respond with “If not Y, then never X.” Sometimes, saying always all the time gets old. An our SME may start to tune it out (always == generally). By reversing the logic, we force them to think about it backwards – usually enough to jolt someone out of the cycle. The logicians out there will recognize this as modus tollens. A sneaky but solid argument. X leads to Y. That doesn’t mean that if we have Y, we must have had X. But it does mean that if we don’t have Y, we can’t have had X. For example: Fire produces heat. There are other ways to make heat (fire is not required), but if we don’t have heat, we definitely don’t have a fire. This can disable the autopilot that SMEs sometimes have when describing a process.
- Apply Other Patterns. Many business processes have a lot of similarities. The folksy phrase “It’s the same, but different” captures the situation perfectly. When interviewing about process X, try and think of similarities or patterns between process X (which you don’t understand yet) and process Y, which you already understand. Try and apply the pattern from process Y to process X – ask if it will work, and then ask why it won’t work. You may find an otherwise hidden step in X, or a need to update Y. For this approach to work, you have to be completely fearless about sounding like an idiot. If you believe stupid questions come from stupid people, then you’ll struggle with this one.
- Ask For Examples. Ask the SME for examples or scenarios that cause a process to behave in a certain way. If you aren’t using a process-centric approach, ask for examples that exercise different business rules. Make sure and get an understanding of the frequency of these examples. Some SMEs will think like a rules-engine, and propose all of the exceptions as examples. Start explicitly with an example of the most common situation. This is analogous to the normal course of a formal use case.
- Create Examples. A merciless way to test your listening effectiveness is to create your own examples, intentionally designed to exercise a particular rule, or create a specific outcome, or test a selected branch of a process. When your understanding has gaps, your examples will have flaws. These flaws are extremely visibile to subject matter experts – and the SME is almost gauranteed to interrupt you to fix your example. These are the exception courses of the use case.
- Draw Stuff. Make truth tables on the whiteboard. Draw flow charts showing branching logic. Add visuals of the different actors – and make them fun. Managers wear ties, engineers have glasses, accountants have eye-shades. Or colors, whatever is fun for you. And name the users, or people, or companies in your examples. These names help a SME (pronounced ‘smee’) to think about a process in the specific, not the abstract. Combining these visuals with examples changes gears for our SME. By changing gears, we are picking the lock of our SME’s vault to get to the good stuff. These examples should poke at the boundary cases, to make sure that we have a good understanding of the process.
These are all refinements, or specific approaches to active listening. Their goal is to get more thorough information from a subject matter expert in less time than it takes to interview repeatedly and iterate on the documents. And they work.