Emerging Tech

Use these interviewing techniques to gather project requirements


There are many ways to gather requirements. Interviewing--where you talk to the people who will define the new solution to determine what they need-- is probably the default technique for most projects.

Interviewing can be an easy process if the person you're talking to is organized and logical in their thought process. Since that's not always the case, however, you have to have employ good interviewing techniques in order to start and guide the interview.

There are a number of formal interviewing techniques that will make the requirements gathering process go more smoothly. Here they are.

Start off with general questions. Typically, you don't start the discussion by asking narrow, targeted questions. You'll want to start more high-level and general questions. These questions should be open-ended, in that they require the interviewee to explain or describe something and can't be answered with a "yes" or a "no." Your goal is to gather as much information as possible with the fewest number of questions.

Ask probing questions. After you ask general, open-ended questions, you should then start to probe for details. Probing questions are probably the most valuable type of questions, since they tend to result in the detailed requirement statements you're looking for.

Be persistent. If you experience any difficulty understanding the interviewee's point, ask follow-up questions. You can also ask for examples that will illustrate the points the interviewee is making.

Ask direction questions when you need additional information. Direction questions start to take the discussion in a certain direction. They're used to provide context and background. For example, "Why is that important to you?" or "Why do you care about that?" are questions that can provide direction.

Ask indirect questions to gain better understanding. Indirect questions are used to follow up on specific points that were raised previously. These questions are used to gain more clarity so that you can ask better questions next. For example, "Is that important because of ..." or "You said everything needs to be secure because…"

Ask questions that validate your understanding. A good interviewing technique is to restate what you just heard back to the interviewee to validate that you understood him/her correctly. For example, after hearing an answer, you could say "If I understand you correctly …”

Paraphrase. This is similar to the prior technique except that you would take a large amount of information from the receiver and simplify it in your own words. For instance, after hearing the interviewee give a five-minute answer on how a process works today, you could paraphrase the basic points of what he/she said in a quick bulleted list of process steps. For example "So, in other words, the process you use today is basically 1,2,3,4..."

Ask for examples. In many (or most) cases of gathering requirements, the interviewer is not totally familiar with all of the information provided by the interviewee. Therefore, one effective way to gain more understanding is to ask for examples. This can also be utilized when the interviewee provides feedback that does not sound totally valid or totally believable. Asking the interviewee for an example helps lend a concrete and specific instance that may help make the requirements clearer. For example, "Can you give me an example of how that affects you?" can help make a statement more clear.

Keep the discussion back on track. Sometimes the interviewee starts to talk about things that are outside the scope of the specific information you're trying to gather. This is sometimes caused by a misunderstanding of the question you asked. Other times it's caused by a lack of focus or a desire to talk about things that are of more interest to the interviewee. When the discussion gets off track, the interviewer must get back on track. An example of this technique would be "That’s a good point. However, can you describe how that relates to (… restate your original question…)?"

Try to stimulate ideas. Sometimes the interviewee gives the obvious answers but isn't thinking about other areas that may not be as obvious. The interviewer should try to get the interviewee to stretch a little and think about things that are not quite as obvious. For instance, you can ask "Can you think of a couple options for this situation?" or "Are there other ways to solve this?"

12 comments
PM Hut
PM Hut

This is the second article by Toni that I read and I and even though I think the article is great, it is a bit repetitive. Btw, people interested in this subject will find this series very useful: http://www.pmhut.com/?s=%22Successfully+Interviewing+Your+Project+Customer+and+Gathering+Project+Requirements%22

mrandmrsraval
mrandmrsraval

yes these are great technique for new it leaders

donstrayer
donstrayer

In my experience the most successful requirements gathering efforts heavily relied on cross-funtional team meetings, preferably held off-site to minimize distractions. All the above excellent interviewing techniques still apply. By getting the stakeholders together and working as a team you're much more likely to drive to concensus about the "real" requirements and priorities so that everyone can feel comfortable signing off.

Mahisri
Mahisri

I read a few good articles written by Tom... this is another good one... like the idea of creating a friendly environment to gather required details. I usually tend to adopt this kind of interview process may be due to my natural behavior. However, others perceive me as over cautious. If you really want to help your company and effectively control scope creep I suggest gathering more details during informal meetings, especially at the bar table. Signing the final scope is rather formal step and unavoidable - they usually sign bluntly and never hesitate to blame pm when the time comes. It is very important to see that they really understand landscape - once again, it can be effectively achieved at the bar table... so budget enough for your informal meetings. Sridhar

jrmorton
jrmorton

Something that works well for me when I'm gathering requirements from the sponsor or key customer is to send the interviewee a "project brief" form to review and complete ahead of time. This is similar to a PMBOK project charter, but more detailed. It stimulates the interviewee's thought process, prepares them for the probing questions, and serves as a roadmap through the interview process. This also helps to keep the interview focused and saves time. Then, after the interview, the brief is updated and the sponsor must sign before we move to the next step.

mford66215
mford66215

And be sure to put in place some version of change management so the project doesn't scope creep out of control. Good article for intro to the topic. How many of you close the requirements meeting by scheduling a follow up meeting where the client will have to SIGN a document outlining the discovered requirments?

Reinard Varela
Reinard Varela

I agree with your technics, specially regarding to get a verification from the interviewee doing cross questions. But, based on my own experience, an important point to consider before to start the interview in itself, is to get a comfortable environment. With just some simple comments (weather, news, etc.), you can create an relaxed atmosphere that will let you do your job in a easier way. Reinard Varela

ShaneHo
ShaneHo

It is worth remembering that every interviewee has an agenda. The interviewee may well be trying to use the interview outcome to justify extra resources, or a promotion or whatever. That's why it is very important to probe behind the initial statements for examples (as Tom suggests) and for supporting data. Don't accept a bland statement that '90% of support calls relate to this application' until you've seen the report for yourself.

Meesha
Meesha

Always sign off requirements. May take more than one meeting but sign off is the baseline for the project.

fabishi
fabishi

Well, I get this always, Going to visit a client having some questions about the tender, but the interviewee is putting the tender out for sale to just fulfill his knowledge then decide of what he wants .... Is there any method to stop government agency or other companies from using free RFI (request for information) as RFP??

Editor's Picks