The hidden cost of broken processes

Broken processes hide because everyone close to them has adapted. The team knows the workaround; the manager knows the escalation path; the customer only sees the delay. What gets reported upward is the official procedure, not what actually happens.

The first is called Little's Law, and it's wonderfully simple:

In plain words: the amount of work sitting in your system equals how fast work arrives times how long each piece stays. Flip it round and it becomes a lie detector: count the work currently in progress, divide by how much you complete per week, and you get your real lead time, whatever the plan says. No assumptions, no exceptions.

The second explains why busy-ness is a trap. For a queue with one server, waiting time grows roughly in proportion to:

where $\rho$ is how busy the resource is, as a fraction of full capacity. Read what that little fraction does. At 50% busy it equals 1. At 80% busy: 4. At 95% busy: 19. Pushing a team from 80% to 95% "utilisation" doesn't add a bit of delay: it roughly quintuples the queue. This is why the department where everyone is flat-out is also the one where nothing ever comes back on time. It's not a character flaw. It's arithmetic.

And unevenness makes it all worse: irregular arrivals and unpredictable task sizes multiply the waiting further. That's why standardising work speeds things up even when nobody works faster.

• Touch time vs elapsed time: hours of actual work inside weeks of waiting. Ratios of 1:20 are common, and disbelieved until measured.
• First-time-right rate: how much work passes through without correction. Every failure is paid for at least twice.
• The cost of one week's delay: price the queue using Little's Law, and the backlog suddenly has a price tag.

Walk one process end to end, as it actually runs, with the people who run it: that's the discipline where the Chido method starts. And if you'd like a second pair of eyes on the walk, that's exactly what a discovery call is for.