Reading P10, P50 and P90 — and where the average misleads you

When an evaluation reports “P10 4.1 — P50 6.8 — P90 11.8 days”, the most common reaction is: “So what is the number?”

The uncomfortable answer: there isn't one. But the three values are easier to read than they look, and each has its own purpose.

What a percentile is

A percentile splits a set of results. P90 = 11.8 days means: in 90 % of cases lead time was shorter than 11.8 days, in 10 % longer.

That is all. It is not a probability, not an accuracy statement and not a safety margin — it is a position in a sorted list.

Why the mean does not belong in that table

In processes the mean is almost always higher than the median, because the distribution is skewed. A case cannot be faster than “very fast”, but it can be arbitrarily slow — one case stuck three weeks in a clarification loop pulls the mean up while barely moving the median.

A worked example with nine cases, duration in days:

2   3   3   4   4   5   6   8   36

• Median (P50): 4 days
• Mean: 7.9 days

The mean of 7.9 days describes none of the nine cases. It sits above eight of the nine. Communicate it as “the lead time” and you are describing a process that does not exist — and anyone who has lived through it will say so.

Which value do you plan with?

It depends on what happens when you are wrong.

Planning capacity: P90. Size staffing to the median and you are understaffed in half of all periods — and since queues accumulate rather than average out, the good days never make up for the bad. At 85 % utilisation you already carry 5.7 times the processing time as waiting; the arithmetic is in How to calculate a bottleneck.

Making commitments: P90, with buffer. A service level of “5 days” against P90 = 11.8 days is not a commitment but a promise broken in one case out of ten — and broken promises generate queries, which load the process further.

Communicating expectation: P50. “Normally seven working days” is honest if P50 is seven. That is the number for the website, not for the contract.

Computing savings: the whole range. A business case saying “saves €45,000” hides that the calculation spans €12,000 to €78,000. Both ends belong in the document — the lower one shows whether the project still carries itself in the unfavourable case.

The three most common misreadings

1. Reading P90 as an upper bound. P90 is not the worst case, it is the value 10 % of cases exceed. The worst case lies above it, often far above — the distribution has no right-hand end.

2. Adding percentiles. The sum of the P90 values of five steps is not the P90 of the whole process. It is considerably larger, because not all five steps hit their unfavourable case simultaneously. Compute that way and you produce numbers that look absurd — and then rightly lose trust in the model.

3. Collapsing the range back into a number. The most common mistake and the most consequential: you compute properly with distributions and then write “6.8 days” into the proposal anyway. The range is the result. Delete it and you did all that work for a figure you could have guessed.

How to write it down

Three formulations that work:

“Lead time is typically 6.8 days. In one period out of ten it exceeds 11.8 days — that is the value we plan capacity against.”

“The saving falls between €12,000 and €78,000 a year, expected value €45,000. Even at the lower end the investment pays back within two years.”

“We commit to five working days. The model puts P90 at 4.2 days — the commitment therefore holds with reserve in nine cases out of ten.”

All three have in common that they state what they do not know. That is exactly what makes them defensible: a number with an honest range survives the critical follow-up question; a number without one does not.

Where the percentiles come from

From a simulation that runs the same process hundreds of times with drawn random values and sorts the results. How that works in detail, how many runs it takes and which distribution to pick is in Monte Carlo simulation for business processes.

They do not come from hand calculation, which yields a point value. That is not an argument against hand calculation: for identifying which step is the constraint it is entirely sufficient. It is simply not sufficient for deciding which number to plan with.