KaizenProof

Lesson 7 of 23 · 7 min read

Working time and waiting time: why office work waits

In Lean: flow, lead time, queues, batches

Builds on: Waiting, Handoffs, Backlog, Searching and switching

In one minute

Any piece of office work spends its life in one of two states: someone is working on it, or it is waiting. Measured from request to done, the waiting part is usually far bigger than the working part, even when every person involved is quick. Queues build up where work arrives faster than it is handled, where it is saved up into batches, and where too many things are started at once. To speed the work up, shrink the waiting, not the effort.

The idea

Pick one item, such as a purchase request or a customer complaint, and ask two questions. How long did it take from the moment someone asked to the moment it was done? That is the time from request to done (in Lean: lead time). And how long did people actually work on it, adding up every step? That is the working time (in Lean: process time, sometimes called touch time).

The difference is time the item spent waiting. In most office processes the gap is striking: minutes or hours of work stretched across days or weeks. Nobody has to be slow for this to happen; it comes from how the work is set up.

Estimating it

You do not need a stopwatch. Take one real, recent item and find when it started and finished: the email date, the ticket history, the approval log. List the steps and estimate each one roughly; you want the shape, not a precise figure. Look at two or three items before you trust the pattern.

Why work waits

Waiting collects in a few predictable places.

  • Work waiting its turn (in Lean: queue). At some step, work arrives faster than it is handled, at least on some days. Every handoff adds one more. One item in a queue is what you feel as Waiting; the queue seen as a pile is a Backlog.
  • Doing work in piles (in Lean: batching). Approvals signed in a weekly meeting, invoices paid in a twice-monthly run. An item that arrives just after the batch waits for the next one, however quick the step itself is. Some batches have a real reason, such as the cost of each payment run; many are habits.
  • Too much started at once (in Lean: work in progress). When a team juggles many items, each one sits still while the others are worked on. At the same pace of work, the more items in progress, the longer each one takes to finish.
  • One path through one role. A step only one role can do becomes a queue whenever that role is busy or away. That is about the design of the step, not the person in it.
Follow one item through the people and tools it touchesA swimlane map of one request, before and after the team removed a step and asked for the missing details up front.

Illustrative example, not real data

A process map before and after removing a stepA swimlane map with three lanes: requester, manager and finance, drawn twice. Before: the requester sends a request, the manager approves it, finance checks it and sends it back because bank details are missing; the requester fixes the details, the manager approves again, and finance pays. Each move between lanes is a handoff where the item waits in a queue. After: the request form asks for bank details, the approval that had never refused a request is removed, and finance checks and pays. One handoff, no rework loop.BeforeRequesterManagerFinanceRequestApproveCheckFix detailsApproveagainPaysent backAfterRequesterManagerFinanceRequest withbank detailsApproveremovedCheckPayA process map before and after removing a stepA swimlane map with three lanes: requester, manager and finance, drawn twice. Before: the requester sends a request, the manager approves it, finance checks it and sends it back because bank details are missing; the requester fixes the details, the manager approves again, and finance pays. Each move between lanes is a handoff where the item waits in a queue. After: the request form asks for bank details, the approval that had never refused a request is removed, and finance checks and pays. One handoff, no rework loop.BeforeRequesterManagerFinanceRequestApproveCheckFix detailsApproveagainPayAfterRequesterManagerFinanceRequest withbank detailsApproveremovedCheckPay
  • A triangle marks a handoff, where the item waits in a queue.
  • Red, dashed boxes are rework: the same work done twice.
  • The approval removed had never refused a request. Removing it is a reversible trial, agreed with whoever owns the control.

Flow

Work that keeps moving (in Lean: flow) passes from step to step with as little stopping as possible. The consequence is uncomfortable but useful: making a quick step quicker barely changes the lead time. If an item gets ten minutes of work spread over nine days, halving the ten minutes changes nothing anyone notices. Removing a queue, shrinking a batch or starting fewer things at once can change the nine days.

Example

Illustrative example, not a real company.

An employee submits a travel expense claim on a Monday and is reimbursed a little over three weeks later. Following that one claim:

  • The manager approves it in a few minutes, but only in a weekly approvals session, so it waits until Friday.
  • Finance checks claims in one block each Thursday, so it waits almost another week, then takes a few minutes to check.
  • Employee payments go out in a twice-monthly run, so it waits again.

Working time: well under an hour, across three people. Lead time: over three weeks. Almost all of it is waiting, and nearly all the waiting comes from three batches. A faster checking tool would shorten minutes and leave the weeks untouched. The useful questions are about the batches: does approval need a weekly session, and could claims be checked as they arrive?

Common mistakes

  • Speeding up the work instead of the waiting. Effort goes into the quickest part, often by automating it, while the queues stay.
  • Estimating from memory. People remember effort, not the days an item sat still. Use the dates on real items.
  • Treating a queue as a people problem. A queue tells you how work arrives and is grouped, not how hard anyone is trying.

Words to know

  • From request to done (in Lean: lead time): the elapsed time for one item, waiting included.
  • Working time (in Lean: process time or touch time): the time someone is actually working on the item.
  • Work waiting its turn (in Lean: queue).
  • Doing work in piles (in Lean: batching): holding items to handle them together.
  • Too much started at once (in Lean: work in progress): items begun and not yet finished.
  • Work that keeps moving (in Lean: flow).

Check your understanding

3 questions. Answer them all, then check. You can try again as often as you like; nothing about your attempts is kept.

Question 1 of 3A new-supplier request took twelve working days from request to done. Adding up every step, people worked on it for about two hours. What is the best reading?
Question 2 of 3Purchase requests in an operations team wait a long time. Which of these are likely causes of the queue? Select all that apply.

Choose all that apply.

Question 3 of 3Monthly management reports take ten days from close to delivery. Work on them adds up to about a day and a half; the rest is waiting for figures from three teams, each sending on its own fixed day. Which change is most likely to shorten the lead time?

Loading…

Try it on your own work

Describe one recurring task that wastes your time, and see these ideas applied to it.

Report a friction (opens in a new tab)

Where this comes from

Comparing lead time with working time and keeping work moving in small batches are central to the Toyota Production System; the link between work in progress and waiting time comes from the study of queues, which Lean practice borrowed.