Handovers Between Departments: Where Deliveries Stall Halfway

Deliveries stall at handovers because work sits in queues until the next department has time, and because knowledge is lost at every handover. In many processes, working time is only a small share of lead time. This article shows how to calculate waiting time at handovers, which five components a handover agreement needs and how to improve handovers in four steps.

Picture a quotation that enters the process on Monday and reaches order processing almost three weeks later. The people involved spent that time on other work. The quotation lay in a mailbox, in a ticketing system or on a list until the next handler was due. Anyone who does not measure this time looks for the cause of long lead times in the wrong part of the process.

Why do deliveries stall at handovers?

Deliveries stall at handovers for three reasons: work waits in queues, knowledge is lost, and nobody is accountable for the result across the departmental boundary. Every department steers its own utilisation. It works off the items it already has, and new items from other departments come afterwards. From the department's point of view this is sensible; from the item's point of view it creates waiting time.

The loss of knowledge follows from the way work is passed on. The person handing over knows the context, and the person receiving gets a document or a ticket. If details are missing, the query begins, and the item travels back or stays put. Finally, in processes across several departments there is rarely one person who owns the delivery as a whole. In 1968 Melvin Conway observed that organisations design systems that mirror their own communication structure. For processes this means that handovers lie at the organisational boundaries, and the course of those boundaries follows the structure of the company, rarely the route of the order to the customer.

How do you calculate the waiting time at handovers?

You calculate waiting time at handovers through flow efficiency, that is, the share of working time in the total lead time of an item. The measure corresponds to the ratio of value-adding time to lead time used in value stream analysis, as Mike Rother and John Shook described it in “Learning to See” in 1999. The calculation has three steps. First, record for a sample of items the pure working time at each station. Then record the time between handover and the start of work at the next station. Finally, divide the sum of the working times by the total lead time.

The following example is illustrative and shows a quotation process across five departments with an eight-hour working day.

In this example people work seven hours on an item that is under way for almost 15 working days. If processing were sped up by half, lead time would fall by three and a half hours, about 3 per cent of the total time. If waiting time is halved instead, lead time falls to just under eight working days, and flow efficiency rises to about 11 per cent. That is exactly why waiting time is the focus. How to track down such waiting times in your own process is described in the article on waiting times in processes.

Why does less concurrent work help?

Less concurrent work shortens waiting time because lead time, work in progress and throughput are linked. In 1961 John Little proved the law named after him: in a stable system the average number of items equals the arrival rate times the average time spent in the system. Rearranged, lead time equals the number of items in progress divided by throughput.

In the example, 45 quotations are in the process at the same time, and the departments complete three items a day. The average lead time is therefore 15 working days. If the departments limit the number of items in progress to 22 and still complete three a day, lead time falls to about seven working days. The limit is a feature of the Kanban method, and the article on limiting work in progress describes how teams introduce it.

What belongs in a handover agreement?

A handover agreement sets out what the handing-over department delivers and what the receiving department commits to. It has five components.

The acceptance criteria correspond to the idea of the definition of done in agile work, applied to the handover. An item counts as handed over only when the agreed details are complete. This moves clarification to the beginning, where it costs little, and relieves the receiving unit of queries.

The response time is the most delicate component because it interferes with the steering of utilisation. A department that picks up items within a day needs capacity that is not fully booked. How utilisation and flow are related is described by Donald Reinertsen in “The Principles of Product Development Flow” (2009): as utilisation rises, queues grow disproportionately, especially where the volume of work fluctuates. It therefore pays to leave critical stations short of their limit.

How do you coordinate handovers across several departments?

You coordinate handovers across several departments by making the whole process visible on a shared level and naming one person responsible for flow. The Flight Levels model by Klaus Leopold separates three levels: the operational work of the teams, coordination between teams and the steering of strategy. Handovers belong on the middle level. There the items of all departments involved come together on one board, and a regular meeting discusses what is stalling. The article on Flight Levels describes these levels in detail, and the article on dependencies between teams adds the question of which dependencies can be dissolved entirely.

Where a process repeatedly passes through the same departments, a further question is worthwhile: can the process be bundled in one team that masters all the steps? Cutting by flow is an organisational decision, and it often works more strongly than an agreement at the boundary.

How do you improve handovers in four steps?

You improve handovers by measuring first, then tackling one bottleneck deliberately and designing the agreement jointly with the departments involved.

1. Map the process: follow 20 to 30 items from receipt to delivery and note working time and waiting time per station.
2. Choose the bottleneck: pick the handover with the longest waiting time and the most frequent queries.
3. Design the agreement: develop the five components with both departments and record them on one page.
4. Measure the effect: after six weeks, compare waiting time, queries and lead time with the baseline and transfer the approach to the next handover.

Handovers and delivery with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the delivery management service area he works as delivery manager, project manager or product owner; in organisational design he shapes roles, decision paths and interfaces.

The approach follows the Niehues Delivery Model with three phases. Three of its test questions matter most for handovers: who decides, who delivers, who uses? Which roles, decision paths and interfaces does operation need? Who is responsible for operation from day one? Scope and terms of an engagement are discussed in the free initial consultation, which you can arrange in 30 minutes through the contact form.