How to map a process without drowning in the detail

Most process mapping fails in one of two directions. Either it stays so high-level that it describes a flow everybody already agreed on and nobody actually follows, or it descends into such granular detail that the team spends four months producing a diagram nobody will ever read.

I’ve been responsible for both failures at different points in my career, which is how I learned to avoid them.

The Understand phase, the U in PURE, has one job: build an honest picture of how the work really happens, who it touches, and where the waste is. Not how it’s supposed to happen. How it actually happens, this week, including the workaround somebody built in 2019 that has quietly become the process.

Eat the elephant one slice at a time

The first discipline is segmentation, and skipping it is the most common reason these projects stall.

If you try to understand an entire operation at once you’ll be drinking from a firehose. You’ll have four hundred observations, no structure to hold them in, and no ability to finish anything because everything connects to everything else.

So segment. First the areas of the business, then the processes within each area. Then start on the ones that are both significant and straightforward, the ones with visible impact and willing stakeholders. You’re not being cowardly by starting with the easy ones. You’re building the evidence and the credibility that will carry you through the hard ones.

The six questions

For each major step in a process, I work through the same six questions. They aren’t sophisticated. They’re just rarely all asked.

Nobody explains their process cleanly

Here’s something nobody warns you about: no person will ever give you a clear, ordered account of what they do. It doesn’t happen. Not because they’re bad at their job, because that isn’t how expertise is stored in a human being.

Even excellent communicators will ramble, skip between topics, start from the bottom with detail when you needed the top-down shape first, use jargon they assume you share, and describe the process as it’s supposed to work rather than as it does. Your job is to steer gently and systematically.

What I’ve learned to do, and what I now coach other people to do:

• Containerize. Mentally group what you’re hearing into categories as it arrives, so the flow starts to make sense.
• Look for themes across conversations, not just within them.
• Segment into logical steps as the picture builds, rather than trying to impose a structure at the start.
• Summarize back frequently. Clarify ambiguity in the moment.
• Draw as you go. Rough diagrams, in front of the person, and invite them to correct you. People will fix a wrong drawing far more readily than they’ll produce a right description.

What you’re really doing is unraveling somebody’s knowledge. It’s a genuine skill and it improves dramatically with practice.

The onion

You can get something from peeling the skin: the surface answers, the obvious pain points, the things people are comfortable saying to someone they’ve just met. To get further you go layer by layer.

The simple truth is that you don’t know enough at the start to ask the questions you need to ask. Each conversation builds the knowledge that makes the next one sharper. Your third interview is always better than your first, because by then you know what to probe.

Which is why I never worry about asking the silly question. You can always frame it: I’ve read the material, but could you give me the beginner’s version? Or: can I play that back to check I’ve understood? Nobody in my experience has ever refused a genuine request to help them be understood. People are scared of looking foolish, and that fear costs them the information they needed.

Hearing is not listening

Hearing is involuntary and effortless. Listening is deliberate and it costs energy: it takes your ears, your eyes, your brain and, I’d argue, some of your attention as a person rather than an analyst.

They tell you about the workaround. About the report they stopped trusting. About the frustration they gave up raising because nothing ever changed.

Listen for what isn’t said, too. The pause before an answer. The qualifier: it works, most of the time. The tone that doesn’t match the words. That’s usually where the real finding is sitting.

How much detail is enough

Here’s the practical test I use: map to the level at which you can see the waste, and no further.

If you can identify that data is being re-keyed between two systems, you have enough. You don’t need to document which field goes where in order to know that the re-keying shouldn’t exist. If you’re documenting keystrokes, you’ve gone too far, and you’ve probably been drawn there by somebody who finds detail more comfortable than conclusions.

I also keep working notes strictly separate from the summary. The notes can be as messy and voluminous as they need to be. The summary that goes to decision-makers should be short, structured and conclusive. Nobody has ever made a better decision because they were handed more raw data.

So what?

The discipline I have to coach people on most often is drawing conclusions.

It’s tempting to present findings as a list. Person A said this. Person B said that. But a list isn’t an analysis. The value is in the synthesis: what are the patterns, what do multiple people agree on, where do they disagree and why, and what’s the root cause underneath the symptoms?

So after every piece of analysis, ask: so what? So what does this tell us? So what should we do differently now that we know it? If the honest answer is nothing, then either the analysis wasn’t worth doing or you haven’t dug deep enough yet. Usually the second.

The output of Understand should be three things, stated plainly: what the process is trying to achieve, how it actually works today, and where the waste and the opportunity are. That becomes the baseline everything else is measured against, and it’s the thing that makes the Reimagine phase a disciplined exercise rather than a leap of faith.