To truly and accurately identify customer need, one has to be able to communicate effectively. One aspect of effective communication in a requirements elicitation context is the ability to organize and ask the right questions in the right way.

To that point, I’d like to refer you to one of my all-time favorite articles on customer interviews by Esther Derby. Below, I expand on a few of her key points on how to prepare for and frame an interview.

1. Have an objective for the interview.

Why do you need to interview the stakeholder? What do you need to get from the meeting? At what level of detail? In my experience, stakeholder interviews have been most productive for myself and, I think, for the interviewee when we have a clear objective in mind at the outset of the meeting.

Once you’ve answered those questions for yourself, it is critical that you share your objective(s) with your interviewee. When you invite the interviewee, tell them what you hope to get out of the meeting. When you begin the meeting, make sure to reiterate those objectives.

Per Derby, “Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.”

2. Think of what questions you’d like to ask.

Again, according to Derby: “Once you have an objective, brainstorm a list of questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions help to identify key topic areas to cover.”

I’ve adopted my own way of doing this where I just open up a new word document, and start typing – it begins as a stream of consciousness/brainstorming-type exercise. Don’t pay attention to the order or flow of the questions at first. That’s the benefit of doing it electronically – you can always cut, paste, and reformat once you’ve exhausted yourself of ideas. Before finishing the exercise, I will sort the questions and categorize them.

3. During the interview, use prepared questions as a guide, not a script.

You may or may not want to even bring a physical list of questions to the interview. If you use an approach similar to mine for brainstorming and sorting questions, you may find that by the time you’ve gone through that process you’re familiar enough with the questions and the general gist of what you want to get out of the interview that you don’t need the printed list.

In fact, if you think having the list of questions in front of you might cause you to rely on it, it’s best not to bring it. We don’t want our progression of questions to be too constrained. To be a successful interviewer it is important to be sensitive to the flow of the conversation so you can adapt the line of questioning accordingly. This is something that may seem tough at first, but gets easier with practice.

Whether you have your questions in front of you or not, flexibility is the key. During the course of the interview you may need to ask certain questions at a different time or in a different way. Some interviewees are easier than others to keep on track. However, I find that as long as the discussion tracks well to the meeting objective and is flowing well, I’m in good shape.

In fact, I often I find that if I’m able to get the customer talking about the problem and the product, I can parse a fair number of requirements out of straight, ordinary dialog that may have otherwise been hard to “extract” by just happening upon the right question. You may miss those requirements if you’re just ticking down a pre-fab checklist of questions.

4. Know your “tools”.

There are lots of different ways to frame questions that elicit different types of responses. For example, open-ended questions are much better than closed (i.e. “yes or no”) questions at drawing out quantities of information and getting the interviewee to talk. Other times you will just want the straight yes or no.

And, of course, my favorite all time question when it comes to getting to the root causes of business problems and their objectives, is the simple – “why?” – repeated as needed.

And finally –

There is much more that can be said about the various types of questions, the types of responses they elicit, and in what situations they’re most useful. My original reason for this post, though, was to share a reference; not to write my own book on the subject. So, I’ll refer you to Derby’s article for lots more information on these and other types of questions that are useful in framing a discussion and drawing out specific types of information.

I bookmarked the article quite a while back – probably 2 or 3 years ago – and I still refer back to it from time to time for my own benefit, and to share as a primer for new business analysts that are looking to hone their elicitation skills.

What are some guidelines to successful interviews that you’ve come across in your experience? For that matter, what are some of your favorite articles on the basics of business analysis? I’d be glad to hear about either or both!