The time work spends waiting

The problem it solves

When a delivery runs late, the question asked in the meeting is who fell behind. It is the wrong question, and it survives because it is the only one that can be answered without data.

Follow one order, case file or request from the moment it arrives until it leaves, noting the time at each change of hands, and something appears that almost nobody expects: for most of its life the work is not being worked on. It is waiting. Waiting for an approval, waiting for somebody to finish something else, waiting for a figure requested by email, waiting for Monday, when someone opens the folder. Total effort is small next to total elapsed time.

This is why the intuitive fixes fail, and each has a price. More speed is demanded from a team already running flat out, which ends up blamed for a delay it did not cause; someone is hired into the area that complains loudest, and payroll rises while the delivery date stays put; capacity is bought where there was spare capacity already. The point that limits the operation is rarely the noisiest or the most visible. It is the point in front of which work piles up, and it is found by looking at the queue rather than at the people. While nobody looks, the queue keeps growing in the same place, and clients learn to call and ask where things stand.

What it covers

This is a measurement workshop, not an opinion workshop, and its angle is time: most conversations about bottlenecks measure how hard people are working, while this one measures how long the work waits. Each participating company picks one bounded flow, an order, a case file, a request or a collection cycle, and follows it end to end with a method simple enough to sustain without systems: mark when the work changes hands and when it stops. In the room, the flow is rebuilt from recent cases and the marks they left behind: the date of the email that brought each one in, the date of each approval, the date of delivery. Where a date is missing it gets flagged, and the gap is already information.

Those timings separate two quantities that are normally confused: the time someone is actually working on the item and the time the item is waiting. Comparing the two usually dismantles the explanation the organization had been using, and that is the part of the session that generates the most argument, because somebody in the room was usually right without being able to prove it. The spread between cases gets examined too: when the same kind of work sometimes goes through quickly and sometimes takes far longer for the same effort, the difference rarely lies in who did it and far more often in how long it sat.

The final part separates three things that get treated alike and are not: a genuine capacity constraint, a queue produced by how work is prioritized, and a wait caused by an external dependency. Every delay in the flow is classified in writing as one of the three, as a group exercise with the evidence on the table, because each is addressed differently and confusing them is how companies hire staff for a sequencing problem. Each company then designs the measurement it will repeat: who takes it, how often, and on what date the next reading happens.

No generic solutions are handed out. You leave with a timing map of the flow, the point that limits it identified and backed by the measurement, every delay classified, and the next reading on the calendar, which is what will later show whether the intervention worked. The decisions that open a constraint, about sequence, capacity or a dependency on a third party, belong to ALUD's Operations engine, and every one of them depends on the measurement this session teaches you to produce.

What participants learn

• Follow a real flow and record handoff times without installing anything.
• Separate working time from waiting time inside a single cycle.
• Identify the point in front of which work accumulates.
• Tell a capacity constraint apart from a priority queue and from an external wait.
• Define a recurring measurement that shows whether the intervention worked.

Agenda

1. 01Cycle time, working time and waiting time: three different measures
2. 02How to follow a real case without installing anything and without stopping the operation
3. 03Handoffs: where work changes hands and starts waiting
4. 04Where work accumulates, and why it accumulates there
5. 05Capacity constraint, priority queue and external dependency
6. 06Why the area that complains most is rarely the one that constrains
7. 07Variability: the same process that takes two days sometimes and ten other times
8. 08What to measure after intervening, and how often

What the organization leaves with

• A timing map of a real flow in your company, with waiting and working time separated.
• The constraint on that flow, identified with the measurement that supports it.
• A written classification of each delay: capacity, priority or external dependency.
• A recurring measurement plan with an owner, a frequency and the next reading date.