Where Work Actually Breaks Down
Here is where operational problems actually live.
The work itself is usually fine. The designer knows how to design. The developer knows how to code. The project manager knows how to track. The delivery team knows how to deliver. The work happens. The work is good.
Then the handoff happens.
The designer hands off to the developer and something gets lost. The developer did not have the context the designer had. The developer makes assumptions. Some of those assumptions are right. Some are not. The client sees the result.
The project manager hands off to the delivery team and something gets lost. The delivery team does not have the client history the project manager has. The delivery team makes decisions based on what was documented, not on what was known. The client experience is different than what was intended.
The delivery team hands off back to the account manager and something gets lost. The account manager did not receive the full picture of what happened, what was decided, and what the client was told. The account manager has to rediscover context that already existed.
These are not work problems. These are handoff design problems. The work was fine. The handoff was not.
Why Handoffs Fail
Handoffs fail for a consistent reason. The person handing off knows what they know. They have the context. They made the decisions. They have the memory of the conversations. When they hand off, they transmit what they said. They do not transmit what they knew.
The person receiving the handoff gets the words. They do not get the context behind the words. They do not get the decisions that were made before the handoff document was created. They do not get the things that were decided in hallway conversations.
The gap between what the handoff document says and what the person handing off knew is where the problems live.
The Handoff Protocol
A good handoff answers four questions that most handoffs do not answer.
What is the current status of everything? Not a summary. The actual current status. Green, yellow, red for each component.
What decisions have been made and why? Not just what was decided. Why. The person receiving the handoff needs to be able to make decisions that are consistent with the decisions that were already made.
What does the client know and what do they expect? The receiving person needs to know what has been communicated and what the client is expecting next. Without this, they will either over-communicate or under-communicate.
What could go wrong and what is the plan if it does? The receiving person needs to know the failure modes that have already been identified and what the response plan is for each one.
A handoff document that answers these four questions takes longer to write than a typical handoff email. It saves hours of re-discovering context that already existed.
How to Test Your Handoff Design
After any handoff, ask the receiving person one question one week later: what do you know now that you did not know when you received the handoff, that you wish you had known?
Whatever they answer is what was missing from the handoff. Add that to your handoff protocol. Over time, your handoff protocol gets better because it is built from actual failures instead of imagined ones.
The most expensive handoff failures are the ones you never find out about. They just show up as client problems, missed deadlines, or quality issues. The protocol fixes that.
