How to Synthesize Interviews

University Process Innovation

Updated April 2016
Executive Summary

Introduction

Business process redesign work heavily relies on information gathering through online
research, and most importantly interviews with key stakeholders in the process.
Interviews provide a vast gamut of information that must be synthesized to develop a
narrative for the process to drive recommendations to improve the process.

Purpose

To develop a holistic view of information gathered from interviews to identify problem

areas and formulate effective recommendations

Target Audience

Anyone conducting a business process improvement project for their unit

Background

The most critical component of any process re-engineering effort involves defining the
core underlying problem(s) in the process. This requires a thorough understanding of
the process at hand. One of the necessary ways to acquire the information about a
process is to interview people who interact with it on a daily basis. While there are
other tools which should be used in parallel, interviewing remains a cornerstone to
knowledge gathering and synthesis. Even though interviewing may be seen as overly
time consuming, acquiring information through a bottom-up process allows for
identification of finite details that may have been missed in a top down analysis. In
addition, a bottom up approach fosters buy-in from people directly involved in the
process, not just the management. Interviews gather a substantial amount of
information, but synthesizing details provides a clear, comprehensive view of the
process.

 
 
 

2
University Process Innovation

Interviewing

Interview Questions

Generally, the first step is developing a set of questions to guide the interview and
make sure key areas of the process are addressed. The questions should be general in
nature and provide an overall framework of the process, but with tailored language
related to the process. Questions that lead to “yes/no” answers should be followed up
with “how” or “why” to probe for further details. Let the interviewee do the majority of
the talking, and only interject to ask clarifying questions, or paraphrase to make sure
you understood what they said. Many times you will need to modify your questions
during the interview, or re-order them based on how the conversation goes. While it is
important to try and touch on all the different topics, it is usually very helpful to follow
the direction of your interviewee as they share important information even if that
doesn’t follow your outlined questions. If you notice that you are getting too far off
track and are discussing things that are out of scope for your project, that may be a
good time to interject and bring the interview back to the topics you outlined.

Interview Documentation

When taking notes during an interview, try to record all of the information provided
from the interviewee and do not worry about organization. The most important thing is
to capture as much information as possible! It is helpful to have another person with you
taking notes during the interview because it may be difficult to lead the interview and
take detailed notes at the same time. A second person may also be able to provide a
different perspective and may also capture details that were overlooked. After the
interview is over and when the information is fresh in your mind, you may want to do a
quick edit to your notes to fill in any gaps that you didn’t have time to thoroughly
document during the meeting.

For more information regarding developing interview questions, and conducting

interviews, reference Chapter 5 of “Workflow Modeling” by Alec Sharp and Patrick
McDermott.

3
Synthesizing Interview Notes

Step 1: Re-read the notes

To start, do a quick read through of the notes starting from the earliest interviews to the
most recent. This will help reacquaint yourself with the content and start mentally
organizing the information. As you are reading through, make mental notes of patterns
of topics and recurring pain points to help guide the compiling process. Do not worry
about organizing any information at this point as it will seem daunting and will take
more time overall than compiling notes later. In addition, start generating ideas for
categories to compile information into.

Step 2: Develop areas of conversation (categories)

Based on information gathered from the interviews, breakdown the process into
categories of functional areas. The categories identify the major milestones that occur in
the process and do not define the sub-processes associated with the process.
Categories should define common threads of information between interviews, which
may show deviations in processes between departments. If you are having trouble
identifying categories, look at areas where additional clarifying questions were asked
about a topic. Once the list of categories is developed go back through the notes and
tag content related to each category. After tagging all of the documents for the content
based on categories compile the information into a single document based off of these
categories. In the interest of time, you can also compile information while
simultaneously tagging information. The end product is an organized set of qualitative
information from the interviews where more robust analysis can be conducted upon.
Categories are also a useful tool to foster buy-in from stakeholders since it frames the
process based on terminology they understand.

Step 3: Align notes with enablers

Businesses processes are extremely complex with various entities interacting around set
guidelines. A business process is assisted from 6 core enablers; process design, IT
systems, motivation and measurement, HR, policies and rules, and facilities. Using the
previously developed categories as a starting point, consolidate the information further
into the respective enablers. The enablers describe how issues are specifically hindering

4
the process. During this process be sure to step through the enablers only focusing on
one at a time. This helps to look in depth at each enabler avoiding a common default to
IT systems. This is beneficial to understand where the trouble areas are in the process
and to develop recommendations that succinctly fix these core functional areas. If issues
potentially go into two different enablers choose the enabler that has higher impact on
the process. For more information regarding strategies on compiling notes, refer to the
“Organizing Interview Notes” document.

Step 4: Create a list of pain points

A pain point is a general area of concern that results in frustration for an actor in the
process. Go back through the interview notes more thoroughly and start generating a
list of the pain points making note of who brought up the statement. Identifying who
said the pain point develops the narrative, and allows for detection of differences in
processes between units, departments, colleges, etc. Adding a question in the interview
directly related to pain points in the process makes the information easier to compile. If
you are having trouble identifying pain points, another effective technique is the
Stakeholder Analysis tool (see supporting documentation) which assembles “what they
like” and “what they do not like” about processes based on actors. The pain points can
then be identified from the information in the “what they do not like” column. It is
important to sift between what is a functional issue with the process, and what is a
personal preference of the interviewee. Some processes inherently require steps that
cause annoyances based on compliance requirements. Enablers can be applied to
decipher between process breakdowns and personal preferences. Next, align the pain
points with the enablers to further develop the narrative for the process. From this
organization, identify the two key enablers that are the area of focus for process
reengineering efforts.

Step 5: Develop a current-state swimlane diagram

Now that the information is organized into categories, and aligned with enablers and
pain points, the current-state swimlane diagram can be developed. Start from the
triggering event and sequentially work your way through the process. Identify senders
and receivers of information to establish hand-off points within the process. Utilize
timeframes provided by the interviewees to identify possible areas where delays occur

5
in the process. This includes IT data dumps/transfers, physical document movement,
supervisor approval, etc. Consistently refer back to interview notes for validation of
process steps, hand-offs, and time delays. Look for patterns that arise in the swimlane
model, which identifies areas of redundancy. If the same actors are involved in a similar
order there is an opportunity to consolidate the steps into a single sequence. Identify
areas where time delays are required to explore the possibility of mitigating these
breaks. Make note of any uncertainties within the diagram that will require further
clarification. Use part of a workshop session to have stakeholders validate the process
steps and sequence of the swimlane diagram. For information regarding how to make a
swimlane diagram, refer to Chapter 8 of “Workflow Modeling” by Alec Sharp and
Patrick McDermott.

Step 6: Identify overall themes

Develop a few (three or four) underlying themes that encompass all of the pain points.
These themes define the cause for action for the process. After developing the themes
for the process, align the themes with enablers of the process. This helps identify what
is specifically wrong with an enabler, and how it is affecting the process. In addition, it
also provides validation that recommendations are fixing not only the underlying issue,
but are implemented within the correct enabler. This shows the direct effect the pain
points and enablers have on the various parts of the process. Use the current-state
swimlane as a source identifying themes too since it visually shows inefficiencies of the
process. From this point, ideation of potential solutions and developing the idealized
state swimlane diagram can start.