The Implementation Gap (Post 1 of 8)
Ask a VP of Professional Services why an implementation ran long, and the answer almost always points at delivery. The consultant missed a dependency. The team was short-staffed that quarter. The customer’s IT department was harder to work with than expected. All of that might be true, and none of it is where the problem actually started. By the time an implementation is visibly struggling, the decisions that made it struggle were made weeks earlier, by people who were no longer involved to see the consequences.
This is the pattern worth discussing before anything else in this series: implementations don’t usually fail because delivery people are bad at their jobs. They fail because nothing was designed to carry the right information from the moment a deal closes to the moment work begins. Sales knows things about the account that delivery never learns. Delivery makes commitments based on a scope document that was written to get a signature, not to protect a timeline. The customer heard promises in the sales cycle that nobody wrote down anywhere delivery could see them. None of this shows up as a single dramatic failure. It shows up as a hundred small gaps that compound into a project that’s three weeks behind by the time anyone officially says the word “at risk.”
The Overrun Pattern Looks the Same Everywhere
Talk to enough delivery leaders and the story repeats with almost no variation. Kickoff goes well. Everyone is optimistic, the customer is engaged, the kickoff deck looks great. Somewhere around week three or four, a decision comes up that should have been made during the sales cycle: a configuration choice, an integration requirement, a stakeholder who needs to sign off but was never identified. The project pauses while someone tracks down an answer. Multiply that pause by the number of decisions nobody made in advance, and a 90-day implementation quietly becomes a 130-day implementation, with no single moment anyone could point to and say that’s where it went wrong.
The financial impact of this is usually understated internally, because it gets absorbed as normal variance rather than counted as a cost. A delivery team that’s perpetually catching up on decisions the sales cycle should have settled is a delivery team that can’t take on the next account on schedule, that burns unplanned hours nobody billed for, and that develops a reputation internally, fairly or not, for being slow. None of that shows up on the deal that overran. It shows up three accounts later, when the team is too far behind to give a new customer the attention that customer was sold.
Why It Reads as a Delivery Problem
Delivery is the team in the room when the friction becomes visible, so delivery absorbs the blame by default. Nobody schedules a retro on the sales cycle that led to an overrun implementation. The account executive has already moved to the next deal, the deal is closed and counted, and the org chart doesn’t have a natural place to have the conversation about what should have transferred and didn’t. So the story that gets told inside the company is a story about delivery execution, even when the actual cause was upstream of anything delivery controlled.
This matters because it points leadership at the wrong lever. Companies that believe their implementation problem is a delivery execution problem respond by hiring more delivery staff, adding process documentation nobody reads, or replacing consultants who happened to be staffed on the accounts that went sideways. None of that fixes anything if the actual gap is between what sales commits to and what delivery is set up to inherit. The team gets bigger, better documented, and differently staffed, and the same pattern shows up on the next account, because the thing that actually needed to change was never touched.
What This Series Is Actually About
The rest of this series is about designing the handoff instead of hoping it happens. That starts with getting specific about what information needs to move from sales to delivery and doesn’t right now, which is where the next post picks up. It continues through scoping practices that protect a timeline instead of just closing a deal, a standardized approach to the first 90 days that doesn’t depend on which consultant happens to be free, and a way of tracking implementation health that catches trouble while there’s still time to do something about it. None of this requires a bigger team. Most of it requires writing down decisions that are currently being made once, silently, in someone’s head, and never passed along.
NextPeak Studio works with growth-stage SaaS companies to close the gap between what gets sold and what gets delivered. If your implementation timelines keep slipping for reasons nobody can quite point to, that gap is usually where the answer is hiding.