The Implementation Gap (Post 3 of 8)
Every implementation starts with a scope document, and most companies assume that document is doing one job when it’s actually being asked to do two incompatible ones. During the sales cycle, scope gets written to close the deal. It’s optimistic, it’s flexible where flexibility helps get a signature, and it tends to describe the ideal version of the engagement rather than the version that’s realistically deliverable in the timeline that was quoted. Once the deal closes, that same document is handed to delivery and treated as though it were written to protect a project timeline, which it never was.
This mismatch is where most scope creep actually starts, and it starts long before anyone on the project uses the phrase “scope creep.” It starts in the sales cycle, in a conversation where the customer asked whether something was included and the account executive, reasonably, didn’t want to be the reason the deal stalled over a feature that seemed minor at the time. Multiply that by every similar moment across a sales cycle, and delivery inherits a scope document with a dozen small ambiguities baked in, each one perfectly reasonable in isolation and collectively enough to turn a defined engagement into an open-ended one.
Two Different Documents Called Scope
The sales-cycle scope document and the delivery-ready scope document are answering different questions, even though they’re often the same piece of paper. The sales version answers “what will get this deal signed.” The delivery version needs to answer “what specifically will be delivered, by when, and what happens when the customer asks for something outside that boundary.” Companies that skip the second document aren’t saving time. They’re deferring the conversation about boundaries from a moment when it’s cheap, before work starts and expectations are still forming, to a moment when it’s expensive, mid-project, after the customer has already started planning around an assumption nobody confirmed.
The cost of that deferral is not evenly distributed. Early in a project, a scope clarification is a five-minute conversation. The customer either agrees the item is out of scope or the two sides agree on a change order, and the relationship absorbs it without much friction. The same conversation held six weeks into the project, after the customer has told their own leadership the feature was included, is a very different conversation. At that point the discussion is no longer about scope; it’s about whether the vendor is trying to nickel-and-dime a customer who thought they already agreed to something. Nobody wins that version of the conversation, and it was entirely avoidable if the boundary had been drawn before staffing began.
Where the Real Discipline Has to Live
A scope document that protects the timeline does a few specific things the sales version usually doesn’t bother with. It lists what’s explicitly out of scope with the same weight as what’s in scope, because ambiguity almost always resolves in the direction of more work unless someone wrote down the boundary in advance. It names the assumptions the estimate depends on, like data quality, the customer’s availability for key decisions, or an integration behaving the way the vendor’s documentation says it should, so that if an assumption turns out to be wrong, there’s a documented basis for adjusting the timeline rather than an argument about whose fault the delay is. And it gets reviewed by whoever will actually run the engagement, not just by whoever wrote the proposal, because the person accountable for delivering the work is in the best position to notice where the estimate is optimistic.
None of this needs to slow down the sales cycle. It needs to happen in the gap between signature and kickoff, as a deliberate step rather than something that gets skipped when the calendar is tight. Companies that build this in as a required stage, not an optional nicety, catch the ambiguities while they’re still cheap to resolve. Companies that don’t are, in effect, choosing to have the scope conversation with the customer during the project instead of before it, at the moment when it does the most damage to trust.
Setting the Boundary Before the Team Gets Staffed
The reason this belongs before staffing, not after, is that a team walks in with a mental model of the project the moment they’re assigned, and that model is hard to reset once work starts. A team that’s staffed against a clear, reviewed scope document starts the engagement knowing where the edges are. A team that’s staffed against the sales deck starts the engagement discovering the edges in real time, usually at the worst possible moments, and usually in front of the customer.
NextPeak Studio helps growth-stage SaaS companies build the scoping discipline that keeps implementations inside their timelines. If your delivery team keeps discovering the real boundaries of an engagement mid-project instead of before it starts, this is the gap worth closing first.