Back

Back

Workflows

Interview or Document: Which to Start With When You Have Both

Process discovery methods compared: what documents give you cheaply, what interviews give you accurately, and the order that wastes least time.

Teamwork in a modern office at night, with laptops, sticky notes, and a city view. A mix of focus, collaboration, and a casual atmosphere.

Of the available process discovery methods, documents are the cheap way to find out what your business believes about itself and interviews are the accurate way to find out what it does, so the order that wastes least time is documents first to build the questions, then interviews to answer them.

Most teams do it the other way round, or do only one, and both mistakes are expensive in different directions.

The two things you are actually trying to learn

Any process discovery exercise is chasing two separate facts, and confusing them is the root of most wasted effort.

The first is the shape of the work. What are the steps, who touches them, which systems are involved, where does it hand off. This is structural, and it changes slowly.

The second is the behaviour of the work. How long does each part really take, where does it stall, what do people do when the official route is blocked, how often does the exception path fire. This is behavioural, and it changes constantly.

Documents are good at the first and useless at the second. Interviews are good at both, and considerably more expensive.

Why documents first

Starting with the documents is not about trusting them. It is about arriving at the interview knowing something.

An interview where you begin with "so, tell me how this works" burns ten of your twenty minutes on structure the person finds boring to recite and you could have read. An interview where you begin with "the procedure says finance approves this before the ticket closes, is that what happens" gets to the interesting part immediately, because you have handed them something to disagree with.

Disagreement is the fastest route to the truth in this work. People are much better at telling you a statement is wrong than at generating a complete description from nothing.

There is a second reason. Reading the documents first tells you what the organisation thinks it does, and the gap between that and what it does is itself the finding. You cannot measure a gap if you only ever collected one side of it.

Where documents mislead

Three specific ways, all worth watching for.

They describe the happy path. The version where the client responds, the payment clears and nobody is on leave. In a lot of processes the unhappy path is a third of the volume.

They have no timestamps. A six-step procedure and a nine-day cycle time look identical on paper, and the nine days are the thing you would actually want to fix.

And they rot silently. A procedure written for a tool you replaced last year reads exactly as convincingly as one written last month. Nothing in the file says which is which, and confidence is not correlated with currency.

Where interviews mislead

For balance, because interviews are not a truth serum either.

People misremember durations, badly. They round up the tasks they resent and forget the ones they enjoy. Almost nobody produces an accurate breakdown of their week from memory.

They also describe the process as designed when you ask a general question, for the simple reason that the designed version is the one that is easy to articulate. You have to ask about a specific recent instance to get past it, and even then you get one instance.

And they are shaped by who is asking. The same person gives a different account to a founder, a consultant and a colleague, not through dishonesty but because they are answering slightly different implied questions.

The order that works

Read the documents for the process you care about. Extract the claimed steps, roles and systems. Do not trust any of it yet.

Interview the person who runs it, about the last real instance, with the claimed steps in front of you as prompts rather than as a script.

Then interview the person immediately downstream. Handoffs are where processes fail, and you only see a handoff properly from both sides.

Then compare the three accounts. Where the document and both people agree, you can stop. Where they diverge, keep pulling.

Running both halves of this together is what abi. FDE does with interviews by voice or text and your SOPs read into the same map, so the documented version and the described version sit beside each other rather than in different folders. The map itself, built by hand, is free on any account. The interviews and the document reading are the paid part.

When to skip one entirely

Skip the documents if you know they are fiction. Plenty of small companies have a process folder that was assembled for a tender in 2022 and abandoned. Reading it will anchor you to a business that no longer exists, and you are better off arriving with no priors at all.

Skip the interviews if the process lives entirely inside one system that logs every transition, and what you need is timing rather than reasons. The log will beat any human account on duration, volume and sequence. It will not tell you why anything happens, but if you only need the where, go and read it.

And skip both if the process runs once a year and involves one person. Write a note in the calendar entry and move on. Discovery effort should scale with frequency multiplied by handoffs, and that product is close to zero here.

The thing neither method gives you

Neither documents nor interviews tell you what to change.

They give you a description. Turning a description into a decision needs two more numbers that discovery rarely collects: how often the process runs, and what an hour of the person's time is worth to the business. Without those you have a very detailed map and no way to rank anything on it, which is a common and slightly demoralising place to end up.

So collect frequency while you are in the interview. It takes one question, it is the number people are most reliable about, and it is what turns a map into a list of things worth fixing.