Process interviews: how to get what you need in one hour

A good process interview takes an hour and has the interviewee walk through one recent, real case step by step, instead of explaining how the process is supposed to run. The second gives you a procedure. The first gives you the process as it actually happens, exceptions included.

It sounds like a detail, but it is the difference between an interview you can use and one you have to follow up twice. Ask "how does contract approval work?" and you get the handbook version. Ask "take the last request you handled, what happened first?" and you hear about the email that never arrived, the colleague who had to take a look, and the spreadsheet where everything is really tracked.

Why process interviews often fall short

Three causes keep coming back.

You ask about the ideal. People describe their work as it is meant to be, especially if their manager will read the notes. Not out of bad faith, but because the deviations have become normal to them. They no longer see them as steps.

The conversation is too broad. "Tell me about your work" produces an hour of background and very little sequence. Without a scoped process and a clear start and end, the conversation drifts towards everything that goes wrong in the organisation.

You are taking notes. Whoever writes along is only half listening. The best follow-up question comes the moment someone mentions something in passing, and you miss that moment while you are still writing down the previous sentence.

Prepare: what you should know before the conversation

An hour is short. Do not spend it on things you could have read beforehand.

• The scoped process. What triggers it, what is the end result, and which part belongs to this person?

• The interviewee's role. Where do they sit in the process, what comes in, what goes out?

• What is already written down. Process descriptions, work instructions, screenshots. Read them, and use them in the conversation: "it says X here, is that still right?"

• A first sketch. Even a rough one. It is easier to correct a wrong model than to have someone describe one from nothing.

How to structure the hour

• 0 to 5 minutes: purpose, scope and consent to record. This sets expectations.

• 5 to 35 minutes: one recent, real case from start to finish. This gives you the process as it actually runs.

• 35 to 50 minutes: exceptions, waiting time and work outside the system. The half that is usually missing.

• 50 to 60 minutes: summarise and play it back. Catch errors while you are still in the room.

The last quarter hour is the one most often skipped, and it pays off the most. A summary you play back out loud ("so the request first comes to you, then...") gets corrected on the spot. The same summary sent by email a week later gets read, approved and forgotten.

Questions that work

Start and end

• What starts this work for you? What comes in, and from whom?

• When is it done for you? What do you pass on, and to whom?

The real case

• Take the last time. What did you do first?

• And then? Where did you look that up?

• Who did you need to ask?

Decisions

• Where can this go two ways? What does that depend on?

• Who decides that, you or someone else?

Outside the system

• What do you track outside the system? A list, a folder, your inbox?

• What do you do when the system does not allow it?

Exceptions and waiting

• When does it go differently from what you just described? How often?

• What are you waiting for? How long?

• What most often goes back to an earlier step?

Questions to avoid

• "How is it supposed to work?" You get the procedure. Ask about the last time instead.

• Leading questions. "The back office checks that, right?" The answer is almost always yes.

• Yes/no questions about the whole process. "Does it usually go well?" teaches you nothing.

• Hypotheticals, too early. "What would you change?" is a good question, but only once you know how it works now. Otherwise you get wishes without context.

Record instead of taking notes

Record the conversation, with consent. An audio recording is enough, nobody needs to be on camera. Then you can listen and follow up, and you only write down the follow-up questions that occur to you.

Say upfront what happens to the recording: who gets to hear it, what it is used for, and when it is deleted. Most people have no problem with a recording once they know it is about the process and not about their performance.

With ModelMatic, the recording then becomes a BPMN 2.0 model straight away, with a summary and the places where information is missing flagged. That changes what you can do with the last quarter hour, or with the follow-up: you do not play back a summary, you play back a process model. At Bovemij, that saves around two hours per validation round, because a worked-out draft is already on the table (read the case). LBIO mapped forty to fifty processes that had never been documented, in a few days of actual working time (read the case).

When an interview is not enough

One-to-one interviews are strong on depth and weak on two things.

Processes that cross departments. Each interviewee knows their own part, and the handovers between departments fall between the conversations. A group session works better there, such as a brown paper session, where people from both sides of the handover stand at the same wall.

Many people doing the same work. Ten customer advisers do the work ten ways, and you usually speak to two. Whether those two are representative, you do not know. How to capture that breadth without booking forty meetings is the subject of a follow-up piece.

An interview remains the best tool for the why behind a process. Use it for that, and let capturing the how take as little of your hour as possible. More on how consultancies use that time in their discovery phase: how to accelerate process discovery.

Want to see what one of your interview recordings turns into? Book a demo and bring one along.