Interviews are probably the most-used elicitation technique in business analysis for a couple of reasons: They’re so easy to do (the business analyst asks a question, the stakeholder responds), and they can be done any time the business analyst and a stakeholder get together, whether in person, over the phone, or via e-mail.
How to prepare for the interview as a business analyst
When preparing for an elicitation interview, think through topics such as the goal of the interview, who your interviewee is and why this matters to him, what type of questions you’re asking him, and what time works best to interview this stakeholder.
Rather than leave scheduling up in the air or fit it in when you can, set up the interview as a meeting. You want your stakeholders to be able to see it on their calendars to both remind them of the appointment and add legitimacy to the interview. Formal scheduling lets them know you’re taking it seriously and that it’s an important part of the process.
Finally, make sure you develop your questions in advance. Although you can let the interview flow along its natural course, you want to have some questions to start with and to go back to, to ensure you’re on track and reaching the goal of the interview.
How to interview the stakeholder for business analysis
If your interviewee isn’t familiar with the project, you may have to give him your elevator speech, a short summary of the project that quickly and simply defines what you’re working on and its value proposition, before you start asking questions. Here are some tips to keep in mind during an interview:
Ask open-ended questions (questions that can’t be answered by yes or no). Your goal is to keep the stakeholder talking. Like in a job interview, the interviewee should be doing about 80 percent of the talking.
Paraphrase what you hear. This tactic ensures that you not only understand what the stakeholder is saying but also are interested in his situation.
Make the session about the stakeholder. Focus on his needs and his problems. Stay away from project-related language as much as possible. The point is that you don’t want to force him to think in terms of what he wants for the project but rather to get him to talk about what his problems are in his business area.
Treat the interview like a meeting. If you scheduled 30 minutes, stick to 30 minutes (or less), and use an agenda (remember those questions you prepared ahead of time?). This approach helps keep both of you from straying too far from the topic. At the end, review any action items you recorded during the interview to ensure you both understand what follow-up items need to be addressed.
Stakeholders are people, too. Just because you’re conducting a business interview doesn’t mean you can’t make small talk with your interviewee. Establishing a common connection increases your rapport with that stakeholder. Remember: If you are doing more listening and less talking, you are doing a great job.
How to document the interview for the business analysis
For maximum results, write up a summary immediately after the interview (because if you’re anything like us, you tend to lose information rapidly as more time elapses from the interview event). Write down the subjects you discussed, the decisions you made, and the action items each of you is responsible for and get the summary to the interviewee.
This documentation doesn’t have to be a formal document. Paul uses outlines (in e-mail and in Microsoft Word), a mind-map (a technique to visually outline information), and even Visio drawings as post-interview documentation. (Note, though, that not all stakeholders are familiar with the mind-map technique.) The important thing is getting the information from the interview in front of the stakeholder in the most efficient and effective way.
After you’ve compiled and sent the document, have the stakeholder confirm your interview summary. Not only does this move keep the stakeholder involved at this stage, but it also shows that you took the interview seriously and are looking for accuracy (and the stakeholder’s confirmation of that accuracy).
This part of the process gives your stakeholder a chance to correct anything in your summary that is incorrect or to clear up any questions you have. Plus, seeing the information again may trigger additional insight or help the stakeholder remember something he didn’t bring up the first time. It’s a way to get him to think about his involvement with the project without having to schedule a follow-up interview.
Having the stakeholder confirm the interview summary not only ensures you captured the information correctly but also helps prevent errors. For example, the stakeholder may have misspoken about something; even though you captured his information correctly, the recorded info is still wrong. When the stakeholder sees the summary, he realizes it’s incorrect and makes the correction.
