Why sales to delivery handover goes wrong
Delivering professional and managed services means building a shared understanding of scope between three audiences: the customer, sales and delivery. I worked on both sides of this at deltatre.com, seven years as a software architect and five as solutions engineer. I can report that, at times, handover can get a little tense.
On the delivery team we built and operated video services across Browser, Mobile and Smart TVs for global content owners. The work was complex and involved integrations between our products and both customer and third-party services. It was also difficult work to estimate.
Handover meetings, while generally upbeat, could sometimes get heated as delivery slowly uncovered a gap between the sales vision and cold reality.
Two things caused most of those gaps:
- Lack of engagement with the right stakeholders during estimation
- Ineffective capture and communication of customer requirements to delivery
After one particularly spicy handover meeting, I was offered a role on the solutions team to try and improve the situation.
On solutions we responded to a high volume of opportunities, mapping complex customer requirements to the services we offered. Each deal was a months-long deep-dive into API documentation, requirement spreadsheets and engagement with both internal and external stakeholders.
Over time, we improved the handover process by comparing what the sales cycle captured with what delivery actually needed. We agreed standard handover artefacts with the delivery team and brought them into the loop long before deals closed. The result: continuity in the customer relationship, calmer collaboration between sales and delivery, and better project outcomes.
Build a knowledge base during the sales cycle
Service businesses often invest huge amounts of time in building a winning pitch. The larger the deal, the more that effort is justified. But the information generated during the pitch, ideation, research, customer conversations, often isn't captured in a way anyone else can use.
From the customer's perspective, the result is frustrating. Discontinuity in the relationship. Repeating themselves. A feeling that their project has been handed from the experts to a bunch of newbies.
Four things stop that interruption of service:
- Centralised digital repository: Store information in one place with a consistent structure. Host customer documents, meeting minutes, customer interactions, and everything else the delivery team will need.
- Official documentation front and centre: Make customer-supplied documentation easy to find. Upload amendments and updates as they arrive so it's always clear which version is current.
- Internal discussions kept on the record: Decisions, tradeoffs, and changes in approach happen during internal meetings. Write down why decisions were made, that context is hard to recover later.
- Customer stakeholder profiles: Sales teams build up detailed pictures of the people on the other side of the deal. The roles, responsibilities, and motivations of those people give the delivery team a head start after kickoff.
The pipeline in Estii
Handover starts before you close
Friction between sales and delivery usually starts when projects are "thrown over the fence" at the last minute. The cleanest fix is to start the handover before the deal closes, giving the delivery team time to absorb the information and, sometimes, feed back into final negotiations.
Four activities belong in the final stages of closing the deal:
- Keep resourcing in the loop: As deals move through the pipeline, sales and resourcing should be talking about likely capacity requirements. Lead times and delivery schedules have to align with reality.
- Identify delivery leads early: Work with resource planners to pick delivery leads before the deal closes. There's a lot to digest, and any extra ramp-up time benefits the project.
- Curate the knowledge base: Once a deal is won, and before handover, organise the documentation. Archive (don't delete) revisions and variations, leaving only the versions finally agreed.
- Create handover artefacts: Condense notes, documents, emails and meeting minutes into the final handover artefacts. The effort reduces cognitive overhead for the whole delivery team.
Resource plan
Build your sales to delivery handover checklist
Several artefacts need to be identified and understood during handover. They guide the project's direction and make sure everyone shares the same context.
Six items belong in a handover pack:
- Solution proposal: A summary of the customer's business, the problem, and the proposed solution. Maps the project at a high level across architecture, design, delivery, testing, and operations.
- Scope, assumptions and estimates: Clear, concise project scope at the right level of detail, structured the way delivery teams think, is the lynchpin of effective handover. Group scope using shared terminology and categories. Each task should carry enough context for estimation and delivery. Include assumptions, exclusions, and feedback gathered from stakeholders during estimation. Fold compliance obligations into scope where they affect the work. If there's one thing to get right, this is it.
- Dependencies and assumptions: What sits outside the delivery team's control, what assumptions manage that risk, and what drives the project timeline. Gather relevant documentation for these dependencies so kickoff doesn't burn time hunting for it.
- Delivery schedule and resource plan: How delivery has been phased in the proposal, and what resource profiles are needed. Resource plans matter for capacity planning, especially where a PMO owns that function.
- Commercial summary: Project commercials aren't obviously a delivery concern, but they give project managers and team leaders useful context. Which rate cards were used? What discounts were applied? What volume assumptions went into TCO? Sharing these puts profitability front of mind.
- Customer stakeholders: Who was involved in the bid from the customer's side, with their roles and responsibilities.
Estii handover documents
Transfer ownership of the project
You've done it, another project in the bag. Now begins the work of bringing a new audience up to speed. If you've followed the advice above, there's a body of useful information ready to brief the delivery team efficiently.
This is also a good chance to look back at the process and spot things to improve on future deals.
Four habits get the most out of the handover work:
- Split information across multiple sessions: Avoid overloading the delivery team. Break handover into meetings on specific topics. It's still useful to have all stakeholders in every session, so cross-cutting concerns build up context.
- Create a channel for asynchronous Q&A: As the delivery team comes up to speed, give them one place to ask sales questions. A Slack or Teams channel works, so does a page in the project wiki. The questions themselves are a good source of ideas for improving handover documentation next time.
- Automate project setup where you can: Structured scope of work is a useful starting point for delivery task management tools. Tools like Estii can export this data in an importable format, including identifiers that let you track estimates against actuals and improve future estimates.
- Keep sales stakeholders available: Some information will never make it into the documentation. Involving the people who ran the sales process gives delivery a direct line to the customer knowledge they need.
Wrapping up
The move from sales to delivery is where promises made during the sales cycle turn into concrete work. Build a knowledge base during the sale. Start the handover before the deal closes. Agree the artefacts delivery needs. Transfer ownership in more than one session. Keep improving the process after every project.
The customer gets a calmer experience. Sales and delivery stop arguing in kickoff meetings. And projects land closer to what was sold.
