When a project stalls, look at the handovers

The delay is rarely where it looks

A project is three weeks late and the plan says the build is behind. The team working on the build is competent and, by their own account, busy. Someone asks for more effort, and the date slips again.

Look one step earlier. In a great many stalled projects, the work that is late is waiting on something that was supposed to arrive from somewhere else: a specification that was never finished, a decision that was assumed, an approval that was requested in a conversation nobody recorded, a handover that happened in principle but not in practice.

Work does not travel between people by itself. It has to be passed, received, checked, and accepted. Every point where that happens is a seam, and seams are where projects quietly lose weeks.

What a handover actually contains

Most teams treat a handover as a moment: the file is shared, the meeting happens, the work moves on. In practice a handover is a small transaction with four parts, and if any one is missing the transaction fails.

The artefact. The thing being passed: a document, a dataset, a design, a decision, an environment, a customer relationship. Not a promise of it.

The context. What the receiver needs to know to act on it. Assumptions made, options rejected, known gaps, what is still uncertain, who decided what.

The acceptance. Someone on the receiving side looks at the artefact and confirms it is usable. Without this, the receiver discovers problems later, after the sender has moved on and the context has been lost.

The ownership shift. A clear point at which responsibility moves. Before that point the sender owns it, after it the receiver does. Ambiguity here is how work falls between people without anyone being negligent.

Four parts, and in most stalled projects at least one is missing at the critical seam.

Why handovers fail

They are implicit. Nobody decided that a handover was needed, so nobody designed it. The sender assumed the receiver knew what was coming; the receiver assumed they would be told when it was ready.

They happen at the wrong level of detail. The classic case: a document is passed with the instruction to proceed, but the reasoning behind the design is only in the sender's head. The receiver either guesses, or asks questions that take days to answer.

They are compressed under time pressure. When a project is already late, handovers are the first thing to be shortened, because they look like overhead. This reliably produces the second delay.

They cross an organisational boundary. Between a client and a supplier, or between two teams with different managers, the seam is wider: different priorities, different definitions of done, no shared shorthand.

There is no record. The handover happened verbally, was understood differently by each side, and cannot be inspected when the misunderstanding surfaces a month later.

Finding the weak seams

You can locate the problem areas without a large exercise. Take the project's chain of work and mark each point where responsibility changes hands. For each one, ask four questions:

1. What exactly is passed, in what form?
2. What does the receiver need in order to use it without going back to the sender?
3. Who confirms it is acceptable, and how quickly?
4. From what moment is the receiver accountable?

Then go further and ask the question that reveals the truth: for the handovers that have already happened on this project, how long did each one actually take from "ready" to "accepted"? The gap between those two dates is usually the delay nobody is measuring.

A second diagnostic is cheaper still. Ask each person what they are waiting for. Handover failures appear instantly, because people are waiting for things that were described as complete.

Design the seam, not the meeting

A well-designed handover is not a longer meeting. It is a small set of agreements about the transaction:

• A defined input. The artefact and its required contents, described in a list of a few items rather than a paragraph.
• A standard of readiness. What must be true before it is passed: reviewed by someone, tested, signed off, accompanied by the decisions log.
• A named receiver, and a named acceptor if they differ.
• A response time. How long the receiver has to accept or return it with specific questions. Two working days is a reasonable default for most work.
• A place it lives. One location, so that the current version is unambiguous.
• A rule for rejection. Sending work back is normal and should not be treated as an insult; it should be cheap and specific.

That list is short enough to write on a single page per project and specific enough to prevent the usual confusion.

Make acceptance an event

The single most useful change in most teams is to make acceptance explicit. Not "the design is done", but "the design has been received and accepted by the person who will build it".

This matters because the sender's definition of finished and the receiver's are usually different, and both are reasonable. The designer is finished when the document is complete. The builder is not ready to start until the gaps that affect their work are resolved. Only an explicit acceptance step surfaces that difference while it is still cheap.

Make acceptance lightweight: a message saying accepted, or a short list of what is missing. The point is the record, not the ceremony. A single shared log with three columns, what was handed over, when it was accepted, and by whom, is enough for most projects and costs a minute per item.

The handovers everyone forgets

Some seams are so structural that they are not seen as handovers at all:

Discovery to delivery. The sales or scoping conversation contains the real requirements, the client's constraints, and the promises made. If none of that reaches the delivery team in writing, delivery will rediscover it slowly and expensively.

Delivery to support or operations. The people who will run the thing need to know how it works, what the known limitations are, and who to call. Handover by proximity ("they sit nearby") works until someone leaves.

Project to business as usual. The final handover is where benefits are quietly lost: the process exists, but nobody owns it, and it decays within a quarter.

Person to person, temporarily. Holiday cover and illness are handovers too. Teams that have never written down how a step is done discover this at the worst moment.

Between phases of the same team. The person who did the analysis moves to the build while the context stays in their head, and the questions come back weeks later.

A short, practical standard

If you want one rule that improves most projects, use this: no work is considered complete until someone other than the person who produced it has accepted it against a stated list of contents.

Everything else follows. Senders learn what receivers need. Receivers stop guessing. The plan's status becomes trustworthy, because finished means accepted rather than finished means "the sender has moved on".

Then add the second rule: when a project is late, examine the handovers before adding pressure. In most cases you will find one seam where work has been parked, waiting for an acceptance nobody scheduled. Fixing that seam usually recovers more time than any amount of extra effort applied downstream.