From the course: Requirements Elicitation for Business Analysts: Interviews

Taking notes during an interview

From the course: Requirements Elicitation for Business Analysts: Interviews

Taking notes during an interview

- There are two types of meeting notes that seem to make me roll my eyes, meeting notes that are painfully detailed, and meeting notes that are so short and vague, I can't glean anything useful from them. Meeting notes can be very wasteful, or can be very helpful and constructive. Let's take a look at some tips and learnings to make the most of your notes from interviews. The first thing that helps us determine the level of detail and type of notes to take is the purpose of the interview. When the purpose of the interview is to build a relationship and meet someone, notes may not be warranted at all. In this situation, notes may actually hinder the meeting, and get in the way of the goal. In relationship-building meetings, you want to be prepared in case something comes up worthy of notes, but you want to be careful not to open up your note pad until that time arises. Opening up your note pad and asking questions to get acquainted sends the wrong message and signal, and does not put the other at ease. You may want to consider taking a few notes when back at your desk about the relationship and some reminders or next steps. For meetings with purposes geared towards vision and high-level project dialogs, you might want to consider taking notes, but they should be very summary-level, you know, to jog your memory about the meeting. Jotting down every word someone says typically will distract you from listening and painfully slow down the meeting. The interviewee was likely explaining evolving thoughts, and would appreciate summary and intent-level notes to feel heard and understood, but likely just doesn't want every detail. For interviews where the purpose is to gather detailed information from someone, you might want to be more about writing and modeling specific information, more precise notes are appropriate. These are the most difficult of interviews to capture notes on. With these, we do not want to capture every single word or phrase spoken, but we do need to capture a lot of detail. Sometimes I get asked if its appropriate to record, voice or video, an interview with a stakeholder, and in most cases, this is not a good idea. And here's my rationale for not recording interviews. They're more likely to be guarded about what they're saying, or perhaps they may be honest, but withhold information, not wanting to be tied to exactly what they said, for many reasons. In requirement solicitation, our goal is to help evolve our stakeholders' thoughts, and create the future. If we're successful in eliciting, their thoughts will evolve and change over time into even better ideas and requirements than they first had. So, recording for the purpose of pinning down what they say, and holding them to that, is actually counter to the essence of what great elicitation is. So, how do we get at capturing all the details that someone's giving us? Here are some options to consider. First is in old-fashioned note taking. This can work quite well. Another option is to use a whiteboard or flip chart in the conference room that you are in, or perhaps within a virtual tool, and have yourself and the interviewee both contribute to key lists, diagrams, visuals, and phrases that summarize the dialog. Then take a picture of it. I love this when both parties are so engaged in the dialog that you're both standing by a whiteboard ready to contribute to a shared understanding. It's very powerful. One of my favorite go-to approaches for capturing details is to prepare for the dialog with a visual model, diagram or another framework. A visual framework or model to fill in. So, for example, if I'm interviewing a subject matter expert on the process that she follows, I'll create a high-level picture of the process, and then below it, I'll create space for each step in the process, and its people, exceptions, systems, and current issues. I come to the meeting with a framework blank, or perhaps just the high level process steps, and then fill in the rest as we chat. Some of the common frameworks I use for detailed requirements notes are things like process models and process maps, and that way we have the related people, systems, forms, exceptions, issues and bright spots. I also use a SIPOC. SIPOC stands for suppliers, inputs, process, outputs, and customers. You may also consider decision tables or decision trees to capture a lot of detail, functional decomposition diagrams, state diagrams, and event response tables, among many others. We are not covering the details of each of these frameworks, but I encourage you to research them if you're not familiar, and try them out as frameworks to help you document meeting notes. Making the most of your meeting notes in effective meetings is about fitting the purpose to the note taking strategy. I hope these ideas give you all kinds of reasons to break out of the traditional note taking mold, and get better interview results.

Contents