Department handoffs are where projects lose their context — fix the handoff, not the project

You sold the project. Discovery went well. The kickoff was scheduled. Two weeks in, the delivery team comes back to sales with three questions that were definitely answered during the discovery phase. Sales fields them, slightly annoyed. The project loses a week.

If this has happened in your company more than twice, it is not an accident or a personality problem. It is the structural reality of how information moves between teams at small companies, and the cost of fixing it is much lower than the cost of continuing to absorb it.

What gets transferred and what gets dropped

Every handoff between two teams involves the transfer of some information and the loss of much more. The deliberate transfer is whatever the outgoing team summarizes into a handover document, a kickoff meeting, or a Trello card. This typically captures the headline facts: who the client is, what was sold, what the timeline is, who the contacts are.

The information that gets dropped is everything else. The objections raised in the third call that shaped how the scope was framed. The off-the-cuff promise the salesperson made about a specific feature. The relationship-management context — which contact is the friendly one, which one to avoid blindsiding, which decisions need to route through whom. The fact that the prospect, mid-negotiation, mentioned a budget constraint that quietly shaped the final pricing.

None of this is hidden. It exists, in detail, in the email threads, the call transcripts, the Slack conversations the sales team had internally about the deal. It is just that none of it crosses the handoff. Only the headline does.

The handoff document is a lossy summary by design

The artifact at the center of most handoffs — call it a project brief, a handoff doc, a kickoff deck — is, by construction, a summary. It is written under time pressure, by someone who is mentally moving on, for an audience that has not yet engaged with the project. The amount of information it can carry is bounded by what the writer can remember to include and what the reader can absorb in one sitting.

The summary works for the first week. After that, the receiving team starts asking questions that the summary did not anticipate, because the receiving team has now actually engaged with the work and is generating new questions that nobody could have predicted upfront.

At that point, the receiving team has two choices: go back to the outgoing team and re-ask (which is what creates the "didn't we already cover this?" friction), or guess. Both options are bad. The first wastes the outgoing team's time and creates the perception that handoffs are incomplete. The second introduces decisions that may quietly contradict what the client was sold.

Project plans don't solve handoff problems

Operations leads, faced with this pattern, often respond by adding more structure to the handoff. A standardized brief template. A mandatory kickoff meeting. A "deal closed" checklist with twenty items.

This helps somewhat. It does not address the root cause, because the root cause is not that the handoff lacks structure. The root cause is that the handoff is the wrong shape entirely. You are trying to compress a multi-month relationship into a one-page summary and a one-hour meeting. The compression ratio is wrong.

What needs to happen is that the receiving team needs to be able to read into the project's history at the moment a question arises, without going back to the outgoing team. The handoff document is fine as a starting point. It is hopeless as a substitute for the original conversations.

The "original conversations" already exist

This is the simple observation that changes the math. Every conversation the sales team had with the prospect is in your email and your call notes. Every internal discussion about how to frame the proposal is in Slack. Every objection that shaped the final scope is recorded somewhere.

The problem is not that the information was lost during the sale. The problem is that the information is not accessible to the delivery team after the sale.

If the delivery team could, when a question came up, query "what did sales discuss with this client about timeline expectations" and get back a structured answer drawn from the actual conversations, the handoff problem would shrink dramatically. Not eliminated — there is still onboarding to do, still relationship context to build — but no longer dependent on the salesperson being available to re-explain.

The handoff between projects, not just teams

The same pattern shows up inside delivery. When a project moves from one phase to another, or from one lead to another, the same compression happens. A summary gets written. The original context is left behind. The new lead starts from a thin brief instead of the actual history.

For long projects, this can happen three or four times. By the time the project is mid-flight, the context the original team built has been compressed and summarized so many times that the version the current team is operating on bears only a sketch resemblance to the original.

The fix is the same: the original conversations need to remain accessible, structured, and queryable, throughout the project's lifecycle. The summary is fine as a starting point for each new participant. The full record is what they fall back on when the summary runs out.

"Will this slow things down?"

A reasonable concern, when proposing that teams can dig into the full history of a project, is that it will create a new kind of inefficiency. People reading back through months of emails instead of getting on with the work.

In practice the opposite happens, because the alternative is not "don't dig into the history". The alternative is "interrupt the outgoing team to ask the same questions". The cost of that interruption — for both sides — is much higher than the cost of a structured query into the existing record.

Once people get used to the model, the pattern stabilizes. You consult the history when you have a specific question. You stop asking the outgoing team for things they already covered. The handoff stops being a fragile, one-shot event and becomes a continuous, optional resource.

What this looks like when it works

At companies that take handoffs seriously, two visible changes happen.

The first is that "kickoff" meetings get shorter. Most of the meeting today is the receiving team asking the outgoing team to re-summarize things. When the receiving team can read the actual record themselves, the meeting becomes about the things only humans can transfer — relationship nuance, gut feel, judgment calls — and lasts forty-five minutes instead of two hours.

The second is that the receiving team stops looking incompetent in week three. The "wait, we already discussed this" moments largely disappear, because anything that was actually discussed is recoverable. Client trust holds. Internal trust between teams holds.

The cheapest project rescue is the one that didn't need rescuing

Project rescues are expensive. The most expensive ones are the ones where the project was actually fine at handoff but quietly drifted off-course because the delivery team was reconstructing the brief from secondary sources for the first month.

Most of those drifts trace back to a handoff that dropped 90% of the context that mattered. The cheapest intervention is upstream of the rescue: make sure the context doesn't get dropped in the first place.

Fix the handoff. The projects fix themselves.