Process Mapping

What Process Mapping Reveals

Process mapping is the technique of drawing out, step by step, the path a piece of work actually takes from start to finish. Done honestly, the result is always surprising. Steps everyone assumed were simple turn out to involve five handoffs. Decisions assumed to be quick involve days of waiting. "We do X" becomes "we do X, then wait, then someone else does part of X, then a different team approves it, then..."

The technique has roots in industrial engineering, lean manufacturing, and Six Sigma, but it adapts cleanly to knowledge work. The 2000s saw it absorbed into BPM (Business Process Management) and the lean-startup community uses simplified versions routinely.¹

The Mapping Symbols

Most process maps use a small set of symbols:

• Rectangles for activities/steps.
• Diamonds for decision points.
• Circles for start and end.
• Arrows for flow.
• D-shapes (delay) for waits.

For agile work, the wait symbol is the most important addition. Standard flowcharts often omit waits because they look like "nothing happens" — but waits are usually the biggest source of total cycle time.

How to Run a Process Mapping Session

1. Pick a specific instance

Don't map "how we do X in general." Map "the last time we did X, what specifically happened?" Concrete instances reveal what abstract descriptions hide.

2. Walk the instance from start to end

List every step. Every handoff. Every decision. Every wait. Resist the urge to skip "minor" steps — those are often where the time goes.

3. Note who is involved

Add the actor or team for each step. Handoffs become visible immediately when adjacent steps have different actors.

4. Mark time

For each step and wait, estimate how long it took. Touch time (active work) and elapsed time (calendar) are different — capture both.

5. Map across a team or several instances

Compare maps. Patterns emerge: which steps consistently take longer than expected, which handoffs are reliable bottlenecks, which decisions reliably stall.

The Common Discoveries

Process mapping for the first time almost always reveals:

• The number of steps is 2–3× what anyone thought.
• The number of handoffs is the biggest source of cycle time.
• One specific step — usually a wait or a decision — accounts for 30–50% of total time.
• Re-work loops nobody had named in writing.
• Steps that are technically "the team's process" but that no one can explain why they exist.

The Most Useful Action: Eliminate Steps

Mapping reveals waste. The natural next step is to eliminate or simplify. Useful questions:

• What would happen if this step didn't exist?
• Why does this handoff exist? Could the prior step's owner do the next step too?
• Is this decision actually necessary, or is it being asked of someone who has no real input?
• Is this wait essential (needed for batch processing, regulatory) or accidental (queue effect, ignorance, habit)?

Most teams find at least one step that exists for no reason anyone can articulate. Removing it usually breaks nothing.

Process Maps vs. Value Stream Maps

Process maps describe how work flows; value stream maps add explicit measurement of waste and value-add time. Both share the same underlying technique. Value stream maps are more rigorous and more time-consuming; process maps are lighter and easier to iterate on. See Value Stream Mapping for the deeper treatment.

Common Failure Modes

• Mapping the ideal, not the actual. The map shows how the team thinks it works, not how it actually works. Test by walking a real instance.
• Mapping too abstractly. Steps like "design" or "build" hide their internal complexity. Decompose until each step has a single actor and a clear output.
• No follow-through. The map gets drawn, photographed, and never acted on. The map's value is in what it changes.
• Over-detailed maps. A 200-step map is unreadable. Group steps when they have one owner and one outcome.

Coaching Tips

Map a real recent instance.

Pick something the team did in the last month. Walk it step by step. The specifics reveal what abstractions hide.

Mark waits explicitly.

Use a different symbol or color for waits. They tend to be invisible in normal flowcharts.

Ask "why" at every handoff.

Each handoff is a place where work changes hands. Some are necessary; many aren't. The asking is the diagnostic.

Find one step to eliminate.

Don't try to redesign the whole process. Find one step nobody can justify and remove it. Build momentum from the small win.

Compare multiple maps.

Mapping three different instances surfaces patterns. Where do all three slow down? That's the leverage.

Re-map after changes.

The first map captures the as-is. Six months later, map again. The trend is what matters.

Summary

Process mapping is the simplest available technique for making the actual flow of work visible. Drawn honestly, the map reveals waits, handoffs, and decisions that everyone tolerated without quite noticing. The natural next step — eliminating accidental steps — produces dramatic cycle-time improvements for minimal cost. Teams that map their process for the first time almost always find at least one step worth removing and one handoff worth reorganizing. The exercise is short; the leverage is high.

Back to Flow & Forecasting