The boxes on a process map are not where the time goes

Most process maps are drawn by asking people what they do. That produces a diagram of the work, which is a useful thing to have and is not the thing anybody drew it to find out. The question that prompted the map was where the time goes, and the time is almost never in the boxes. It is in the white space between them, which the map does not draw at all.

So here is one claim, followed end to end, with the gaps recorded rather than the steps.

One warranty claim

A domestic appliance warranty claim. Seven steps. Somebody read the timestamps off the case record and wrote down two figures for each step: how long the claim sat before the step started, and how long the step took once it did.

---

	Working time, the seven steps added up	64 min
	Waiting time, the seven gaps added up	98.0 h
	Elapsed time, working plus waiting	99.1 h
	Elapsed time on an eight hour working day	12.4 days

Illustrative figures, and every one of them comes from timestamps the case system already holds. Just over one percent of the elapsed time is work, which is not remarkable: most administrative processes measured this way come in under five percent.

Sixty four minutes of work in twelve and a half days. Now look at the map that would have been drawn for this process. Seven boxes, seven step names, and the total of the numbers written inside them would have been about an hour. Nothing on that map accounts for ninety eight of the ninety nine hours the claim actually took.

Four kinds of waiting

Here is where the exercise stops being an audit and becomes useful. Not all waiting is the same, and the differences decide what to do about it. There are four kinds, they are easy to tell apart, and only one of them is a capacity problem.

A batch wait. The item is finished and waits for a scheduled departure. Approvals run on Tuesdays, the file goes to the bank at four, the report runs overnight. Nobody is busy and nothing is missing. The item is waiting for a calendar.

A queue wait. The next step is genuinely occupied with other items. This is the only one of the four that is a capacity problem, and it is the one everybody assumes they have.

A handoff wait. The item has arrived somewhere and belongs to nobody. It is in a shared mailbox, a tray, a folder somebody checks when they remember. Nothing is being done to it because nothing has been assigned.

A dependency wait. The process is waiting on something outside it: the customer, a supplier, a signature, a part. Real, often unavoidable, and usually much more movable than it looks.

Sort the seven gaps into those four and the shape of the problem changes completely.

---

	Batch, the weekly approval run	40.0 h
	Dependency, waiting on the customer for photographs	31.0 h
	Queue, three steps where the next person was busy	17.5 h
	Handoff, two steps where the claim belonged to nobody	9.5 h
	Share of the waiting that is a capacity problem	18%

The three queue waits are the assignment step at 1.5 hours, assessment at 14.0 and settlement at 2.0. Everything else in the ninety eight hours is a schedule, a mailbox or a customer.

Eighteen percent. That is the entire capacity problem, and it is the thing the department has been asking for headcount to fix, because assessment is the step people can see and it visibly has a queue in front of it.

What each fix is worth

Take them in order of size rather than in order of visibility.

The forty hour batch. Approval runs once a week. This claim arrived just after a run and waited nearly the whole interval. Move the run to daily and the same claim waits at most eight hours.

---

	Waiting before, all seven gaps	98.0 h
	Approval wait, weekly run	40.0 h
	Approval wait, daily run	8.0 h
	Elapsed time, waiting plus 64 minutes of work	67.1 h
	Elapsed time, was 12.4 days	8.4 days

Four working days removed from every claim in the process, for a change to a meeting schedule. No system, no headcount, no capital.

The thirty one hour dependency. The photographs are requested after triage, so the customer’s response time sits in the middle of the process with everything stopped around it. Ask for them in the acknowledgment that goes out on receipt and the customer’s time runs alongside the first two steps rather than after them. The customer still takes as long as the customer takes. The process reclaims the seven and a half hours it was spending on receipt and triage while nobody had asked for anything yet, which brings the claim to 7.5 days.

That is a smaller number than the batch fix and do it anyway, because it costs a change to a template, and because a request made once at the start is a request that does not have to be chased.

The seventeen and a half hours of queue. This is the one that costs money. An additional assessor might halve the fourteen hour wait at assessment, taking the claim from 7.5 days to 6.6.

Line those three up and the argument makes itself. Two changes that cost nothing take twelve and a half days down to seven and a half. The change that costs a salary takes seven and a half down to six and a half, and it is the one the department was going to ask for first.

Drawing the map so it shows this

None of the above needs new instrumentation. It needs the map to be drawn about the item rather than about the department.

Record three times per step, not one. When the item became available for the step, when the step started, when the step finished. The gap between the first two is the wait, and it is the number the whole exercise exists to collect. Most case systems already hold all three and present none of them.

Follow one item first, all the way through. Not an average and not a summary. One real case, with its actual dates, including the parts that are embarrassing. An average lead time tells you the process is slow. One followed case tells you where, and it takes an afternoon.

Classify every gap before discussing any of them. Write batch, queue, handoff or dependency beside each one. Do this before anyone proposes a fix, because the classification is what makes the fix obvious and the proposals made without it are nearly always for capacity.

Then take a sample. One claim is an anecdote. It is enough to build the map correctly and it is not enough to size anything, because a single case cannot tell you whether its forty hour approval wait was typical or the worst of the month. Ten cases will. Choose them at random rather than the interesting ones. The interesting ones are the tail, and the tail is a separate question from the ordinary case.

The reason this is not obvious

Processes are mapped by department, because departments are who you interview and who signs off the map. A department knows what it does and how long it takes. It does not know how long the item waited before reaching it, because that wait happened somewhere else, and it does not know what happened after, because the item left.

So every department in the chain can report accurately and truthfully that its part takes under half an hour, and every one of them is right, and the claim still takes twelve days. Nobody is hiding anything. The information was never assembled, because assembling it requires following the item across boundaries and nobody owns the item, only the steps.

That is also why the fix is so often free. Waiting that nobody owns is waiting that nobody has ever been asked to defend, and a forty hour approval batch survives for years not because anyone decided it was worth forty hours but because nobody has ever seen the forty hours written down.

The other half of this measurement, and the reason the two numbers must never be reported as one, is that working time and elapsed time respond to completely different things. That distinction is worth having straight before any of the above is presented to anybody.