Scope creep isn’t a contract problem. It’s a conversation you didn’t have.

The first is when sales conversations happen in a vacuum. Only biz dev and client stakeholders in the room. Conversations stay theoretical rather than tactical. The team never breaks work into discrete, estimable pieces — underscoping by omission. A heavy reliance on past similar projects as the estimation baseline compounds it. That instinct isn’t wrong — pattern recognition has value. But the lessons learned from those baseline projects, including any scope creep that occurred at the time, rarely make it into the new projection. The cycle repeats: The team passes an underscoped baseline forward, stripped of the context that would have made it useful.

The second reason is an attempt to fix the first: A delivery team member joins the sales conversations. This helps. It introduces more accurate estimation, surfaces technical nuance, and sets more realistic timeline expectations. A real improvement — but still not the complete picture.

The third reason is the most consequential. The delivery person in the room isn’t the person who will do the work. A senior engineer with 20-plus years of experience joins the sales conversation. They speak fluently to the client. The client walks away confident. The project kicks off — and the team that shows up is different. A capable technical lead, maybe eight to ten years of experience, solid but not the same person the client met. Someone who won’t be implementing made the estimation. That gap between who estimates and who executes is where the real damage happens.

All three of these reasons are valid. And all three trace back to the same root cause: gaps in communication. Either the right things weren’t said, or the right people weren’t in the room to say them.

These two get collapsed together constantly, and that’s part of why scope creep is so hard to address.

Underestimating is a math problem. The team guessed 40 hours; it took 80. That’s painful, but it’s a calibration issue. The team learns from it, adjusts the formulas, and builds in contingency.

Underscoping is a different animal. It’s not that the estimate was wrong. It’s that no one ever fully defined the thing being estimated. A feature request comes in as a sentence. Nobody asks the follow-up questions. The contract reflects the sentence, not the system behind it. And when the team starts building, they discover the sentence was actually a paragraph, which was actually a chapter.

The cost asymmetry matters here: Underestimating costs time and money on a known thing. Underscoping costs time, money, trust, and often the relationship. Now the team is delivering something different from what the client thought they bought.

This is the organizational politics piece, and it’s the one nobody likes to say out loud.

In a lot of agencies and a lot of client organizations, estimation happens upstream of the people who will actually execute. A business development lead scopes a project, a proposal goes out, the client signs a contract. The delivery team inherits it. If they’re lucky, they get a discovery phase to pressure-test the assumptions. If they’re not, they’re building to a scope someone wrote without knowing what they didn’t know.

This isn’t a character flaw. It’s a process design problem. When the people closest to the work don’t have a seat at the estimation table, the gaps between what was promised and what’s possible get baked in before the project even starts.

The fix isn’t to exclude sales or strategy from scoping conversations. It’s to make sure delivery has a voice in them. Early, not after signing the contract.

Most frame scope creep as an agency problem. But clients are often the other party in the conversation that didn’t happen.

Stakeholder alignment on the client side is genuinely hard. The person who signs the contract and the person who reviews the deliverables are frequently not the same person. New requirements surface mid-project, not because anyone is acting in bad faith, but because the organization’s own internal conversation hadn’t happened yet before anyone defined the scope.

A product owner can have a strong vision for what they want to see on the site and still have very little visibility into what it takes to build it. Implementing a feature on one part of the site can have real consequences for a feature somewhere else entirely, like a part of the site no one is actively touching. Those connections aren’t visible from the product side. They’re only visible from inside the code.

We know this firsthand. On a complex engagement, we ran into this exact situation. One person coordinated acceptance criteria. Neither team questioned that setup enough. No one discussed it with enough granularity. The work had downstream implications that were real and consequential and we weren’t surfacing them early enough. This resulted in a gap between what the client expected and what got delivered.

Together, we realized that one person owning acceptance criteria wasn’t enough. When multiple product owners are in play — each with their own assumptions and context — a single sign-off isn’t really a sign-off. It’s a gap waiting to surface.

So what does the conversation you should have actually look like?

For us, it came into focus during the process of working through that engagement. Three things changed.

First, we built discovery time into every single ticket and rethought how we story pointed on an inherited codebase. Discovery is no longer a phase to sell, it’s a line item in every estimate. We account for the upfront conversation before anyone writes a line of code. We also padded our story point estimates to reflect the reality of working in a legacy system. A ticket that would typically be pointed at a five became an eight. That additional runway gave the team space to navigate complexity, regression, and unexpected dependencies during implementation without blowing the timeline. Unconventional by standard story pointing practices, but warranted by the work.

Second, the value of group-defined acceptance criteria became clear. When everyone who has a stake in the outcome also has a voice in defining what “done” means, the gap between what was promised and what gets built closes. Developers weigh in. Technical constraints surface before implementation, not during. One person’s vision plus the team’s technical reality equals acceptance criteria that holds up.

Third, we stopped shortchanging our status meetings. The workflow already includes them as the most natural home for these harder conversations. Squeeze them down to ticket updates, and the team will never make time for the discussions that actually prevent scope creep. Don’t give away time that’s already built into the process.

It looks like slowing down before the contract and bringing the delivery team into scoping before the proposal goes out. It also means asking clients not just what they want, but who else in their organization needs to weigh in, and giving that process real time and structure.

It looks like treating a statement of work not as a finish line, but as the beginning of a shared understanding that needs to be tested, not assumed.

Scope creep will never go away entirely. Projects are living things, and requirements evolve. But the version that comes from a conversation nobody had? That one’s preventable.