Which unfinished work is moving?

A busy week can leave the oldest work exactly where it was. To find out whether a queue is improving, count what arrives and what finishes, then check which unfinished items remain.

Imagine a small equipment-repair shop. It begins Monday with twelve open repair requests. The following ledger is entirely invented. A request counts as completed only when the agreed work is finished, checked and the customer has been told it is ready for collection. That definition stays the same all week. There are no cancellations or other closures in the illustrated week.

One week of repair requests

Scroll across to see every column. Use the arrow keys when the table is focused.

The shop received thirty-six requests and completed thirty-six. It ends with twelve open, the same count it started with. Friday's ten completions are encouraging. None of those facts tells us whether the original twelve customers have been served.

Follow the opening twelve

Now add the request records. Only six of Monday's opening twelve were completed during the week. Thirty of the thirty-six new requests were also completed. Friday's remaining twelve therefore consist of six older requests and six new ones.

The shop has done substantial work. It has also left half of its opening queue unfinished. A report listing only thirty-six completions would hide that second fact.

Age does not establish priority on its own. An older request may be waiting for a customer to decide whether a repair is worthwhile. A new request may involve an urgent commitment the shop has already accepted. The records need enough context to distinguish those situations.

In this example, the six older requests have two different obstacles:

• Four are waiting for customers to approve written repair estimates. The estimates were sent, but no one owns following up or recording when a decision is due.
• Two need replacement parts. The orders exist, but the shop has no confirmed arrival dates.

Of the six newer requests still open, three are being repaired and three await initial inspection. That accounts for all twelve. There is no single task called “clear the backlog” that would resolve every one of them.

Act on the part that is stuck

For the four undecided estimates, the service lead checks that each customer received the estimate, answers outstanding questions and agrees on a next contact or decision date. A message sent is still waiting, not approval. If a customer declines the repair, the shop records that outcome separately and arranges return of the equipment; it does not relabel the request a completed repair.

For the two parts orders, the purchasing lead obtains actual availability and delivery information. If a part is unavailable, the shop needs a decision about an alternative or a revised arrangement with the customer. The technician cannot finish a repair with a reassuring internal status.

The inspection queue calls for a different response. The shop can examine the work and time required for those three requests, the promises already made and who can inspect them. More repair capacity might help there. It does not supply missing customer decisions or make the ordered parts arrive.

Those actions may release work, reveal a longer wait or establish that a repair will not proceed. Record what actually happened. Keep completed repairs, customer cancellations and other closures distinct so that a cleaner-looking queue does not conceal a worse service result. In a week with cancellations or other closures, record those as separate exits in the ledger.

The count cannot promise a date

The shop averaged 7.2 completed requests per working day. Dividing Friday's twelve open requests by 7.2 gives about 1.67 working days. It would be a mistake to turn that calculation into a promise that every remaining repair will be ready within two days.

The twelve are a snapshot, not an average queue measured over time. Some repairs need parts; others need permission or an inspection. New requests will keep arriving. Their work requirements and priority may differ. The division has not established when any particular request can finish.

John D. C. Little's 1961 queuing result relates the mean number in a system, its mean flow rate and mean time in the system under stated mathematical conditions. That relationship between averages does not turn this Friday's count and a single week's output into individual delivery dates.

Follow three requests from start to finish

A request can spend much longer in the system than someone spends working on it. Consider a separate invented ten-minute record, with no work open before minute zero. Three requests arrive and all three finish within the record. Finishing includes the repair, check and readiness notification.

• A: arrives at minute zero and finishes at six. Work on it takes place during minutes 1–2 and 5–6.
• B: arrives at minute two and finishes at eight. Work on it takes place during minutes 3–4 and 7–8.
• C: arrives at minute four and finishes at ten. Work on it takes place during minutes 9–10.

The work intervals include every required step. There are no other arrivals, cancellations or closures. Each request spends six minutes in the system. Average time from arrival to finish is therefore six minutes.

The active work totals five minutes: two for A, two for B and one for C. Here, waiting means time inside the system outside those active intervals. It totals thirteen minutes across the requests. That is not thirteen minutes on the clock: requests can wait at the same time.

Now measure the unfinished count throughout the ten-minute window. It is one for minutes 0–2, two for 2–4, three for 4–6, two for 6–8 and one for 8–10. Multiplying each count by its two-minute duration gives eighteen request-minutes. Divide by ten minutes to obtain an average of 1.8 requests in the system.

The completion rate is three divided by ten, or 0.3 requests per minute. Here, 1.8 divided by 0.3 gives the same six-minute average arrival-to-finish time. Every request is observed from arrival through finish within this window. This complete record supplies the three averages; Friday's snapshot did not.

The result does not mean each request needed six minutes of active work. Nor does it promise that the next request will finish in six minutes. The record has not shown why the requests waited. Find that out before deciding which change would help the next customer.

Choose the boundary of your own queue before measuring it. In this example, a completed repair leaves the queue at readiness notification; other closures would be recorded separately. If customers then wait several days for collection, that is another elapsed time worth understanding. Calling the repair ready does not establish that the customer has the equipment back.

Bring the record to the next review

Chapter 16 of Infinite Upside asks whether a process reaches a meaningful finish. Producing more beginnings can create more unfinished work. That concern applies whether a person or an automated process moves a request from one stage to another.

Keep a short record for each open item: when it arrived, the promised result, its present obstacle, who can act and when the situation will next be checked. At the following review, return to this week's older six as well as the new total. Which decisions arrived? Which parts became available? Which request finished, and which commitment needs to change?

If arrivals repeatedly exceed completions, examine the work being accepted and the operation's ability to finish it. If the total stays level while old requests age, examine selection and waiting. If completed repairs rise but customers remain without usable equipment, follow the service beyond the boundary being counted.