Variation
The average was met and a quarter of the orders were late
Twenty orders, a mean of six days against a six day promise, and five of them over it. The number that would have told you is not the average, and it is not hard to compute.
A team promises six days. At the end of the month the average is six days and the tile on the dashboard is green. Meanwhile the complaints have not stopped, the escalation log is the same length it was, and somebody senior is asking why the numbers and the phone calls disagree.
They do not disagree. The average is right, the complaints are right, and the average was never capable of answering the question anyone was actually asking. This is not a subtle statistical point. It takes one column of data and about four minutes to demonstrate, and it changes what a team reports for good.
Twenty orders
Here are the twenty orders that made that average, in days from receipt to despatch, sorted so they can be read.
| 2 | 2 | 3 | 3 | 3 | 3 | 4 | 4 | 4 | 4 |
| 4 | 5 | 5 | 5 | 6 | 7 | 9 | 12 | 14 | 21 |
They add to 120, so the mean is exactly six. The promise is six. Target met.
Every order in the table above is a dot. The mean and the promise land on the same line, which is why the tile is green. Five orders sit to the right of it.
| Mean, the twenty added and divided | 6.0 days | |
| Median, the middle of the sorted list | 4.0 days | |
| Orders over the six day promise | 5 of 20 | |
| Ninetieth percentile, the eighteenth of twenty | 12 days | |
| Share of orders that missed the promise | 25% |
Illustrative figures, and every line is reproducible from the twenty numbers above with no tools beyond a sorted column. The percentile here is taken by rank: the eighteenth value of twenty for the ninetieth, the nineteenth for the ninety fifth, which comes to 14 days.
Four descriptions of one month. The mean says the promise was kept. The median says the typical order took four days, comfortably inside it. The count says one order in four missed. The ninetieth percentile says the unluckiest one in ten waited twice the promise.
All four are correct. Only two of them describe anything a customer experienced, and the one on the dashboard is not among them.
Why the mean fails here specifically
The mean and the median are the same number when the data is symmetric. Process times are almost never symmetric, and the reason is structural rather than statistical: there is a floor and no ceiling.
An order cannot take less than the work in it. That sets a hard lower bound of about two days here, and no amount of good luck gets below it. There is no matching upper bound. An order can miss a batch and wait a week, sit behind an absence, need a part, or hit a query that nobody answers, and each of those adds days without limit. The distribution has a short left side and a long right one, so the mean gets dragged up above the middle by a handful of large values, and it stops describing the typical case without ever stopping being the average.
That single order at twenty one days moves the mean by three quarters of a day on its own. Remove it and the average drops to 5.2, the dashboard goes greener, and nothing whatsoever has improved for anybody.
Which is the trap. On a skewed distribution, the mean responds most to exactly the cases you have not fixed, so it can be improved by having a quiet month rather than by doing anything.
What to report instead
Three numbers, and none of them needs a system change.
The share that missed. The most useful single figure a process can publish, because it is denominated in customers rather than in days. Twenty five percent missed. That is a sentence anyone in the business can act on, and it does not move when one order goes badly wrong.
The ninetieth percentile. What the unlucky tenth experienced. This is the figure to quote when making a promise, because a commitment set at the mean is a commitment you will break a quarter of the time by construction. Set it at the ninetieth percentile and you break it once in ten.
The median, if you want a typical case. Four days here. It is what most orders actually took, it is stable, and it is the honest answer to the question the mean is usually asked to answer.
Report all three and the month above reads as: typically four days, one in four missed six, the worst tenth waited twelve. That is three numbers, it fits on one line, and nobody who reads it is surprised by a complaint.
The part that is not about reporting
There is a second, larger reason to care about the spread, and it is not a measurement question at all. Variation is what creates the queue in the first place.
The relationship was published by John Kingman in 1961 and it is an approximation rather than an identity, accurate where a process is busy and rough where it is quiet, which is the right way round. It says the waiting in a queue is the product of three things: how busy the process is, how variable the work and its arrival are, and how long the work takes.
The middle term is the one nobody manages. It is measured as the spread of the handling time divided by its average, a ratio with no units, and it enters the answer directly.
Take the approvals desk from the piece on utilization: eighty percent busy, eight minutes a request on average.
Waiting ≈ (ρ ÷ (1 − ρ)) × ((Ca² + Cs²) ÷ 2) × handling time
| ρ | Utilization, unchanged | 0.80 |
|---|---|---|
| Ca | Spread of the gaps between arrivals, unchanged | 1.0 |
| Cs | Spread of the handling time, halved from 1.0 | 0.5 |
| Wq | Average wait before being started, was 32 min | 20 min |
Nobody worked faster and the average handling time is still eight minutes. Only the spread around it changed, and a third of the waiting went with it.
Read that again, because it is the argument. The average handling time did not move. The volume did not move. Nobody was hired. The spread of the handling time halved, and the waiting fell by more than a third.
The whole curve, at that same desk:
| Spread of the handling time | Waiting |
|---|---|
| 0.0, every request exactly eight minutes | 16 min |
| 0.5 | 20 min |
| 1.0 | 32 min |
| 1.5 | 52 min |
| 2.0 | 80 min |
The top row is worth noticing. A desk where every request took exactly eight minutes, with no variation at all, would still hold a queue, because the arrivals are still irregular. Variation on either side is enough on its own, which is why removing it from one side is worth doing even when the other side is out of your hands.
What to do on Monday
Stop reporting a mean on its own. Add the share that missed and the ninetieth percentile. This is a spreadsheet change and it takes an afternoon.
Plot the twenty numbers. Not a summary, the actual values, sorted. Every process has a shape, most teams have never seen their own, and the shape usually names the problem before any analysis does: a cluster with a long tail is a small number of cases going badly wrong, and a genuinely wide spread is the ordinary work being done inconsistently.
Go after the tail rather than the average. Find the five orders that missed and read what happened to each. In almost every case the tail is not slow work, it is a different path: an exception, a query, a rework loop, a case that fell out of the normal route. Removing the cause of a tail removes it for good, and it improves the mean as a side effect rather than as a target.
Then look at the spread of your ordinary work, because that is the term in the queueing relationship that responds to standard work, to clearer instructions and to taking exceptions off the main path. It costs nothing, it is invisible on a mean, and it is the reason two teams with identical average handling times can have completely different queues.
None of this changes how long the work takes. It changes what is known about it, and the difference between a process that is measured by its average and one that is measured by its spread is that only the second one can be argued about usefully. Where the time is actually going, step by step, is the separate measurement that has to come first.