Every agency has a version of the same story. A project starts clean — brief in, plan out, timeline agreed. Six weeks later, something has changed. Maybe the client added a microsite. Maybe the integration turned out to be more complex than the API docs suggested. Maybe nobody scoped the content migration properly.
By the time the project closes, it's over time, over budget, or both. The team gets a post-mortem. Lessons are "documented." The next project starts clean again.
This is not an execution problem. It's a scoping problem.
That number has been stable for over a decade. Agencies have adopted better project management tools, more sophisticated contracts, and more experienced teams — and the overrun rate has barely moved. Which suggests the problem isn't discipline. It's the scoping process itself.
Three root causes — not one
When agencies blame "scope creep," they're usually describing the effect, not the cause. Scope creep is what happens when a project grows beyond what was agreed. The question worth asking is: why does that happen so consistently?
The data points to three independent root causes. They often appear together, but each can produce overruns on its own.
Manual estimation bias
Human estimators systematically underestimate complexity. This isn't incompetence — it's a documented cognitive pattern called the planning fallacy. When a senior developer scopes a task, they estimate based on the best-case scenario: the integration works, the client delivers assets on time, the API documentation is accurate. These conditions are rarely all true simultaneously. The result is estimates that are correct in isolation and wrong in aggregate.
Scope creep compounding
Small changes don't stay small. A single client change request that adds 5% to the project scope doesn't just cost 5% — it cascades through dependencies. The redesigned component needs new templates. The new templates need new content. The content needs migration. Each addition triggers downstream work that wasn't in the original scope, and each downstream item has its own estimation uncertainty. In complex digital projects, change requests compound at roughly 1.3–1.7× their stated size once dependencies are accounted for.
Client brief ambiguity
Most client briefs are written to communicate intention, not to specify scope. "We need a new CMS" can mean a $40k migration or a $200k rebuild, depending on content volume, integration requirements, and performance targets that the brief doesn't mention. Agencies that scope directly from briefs without structured disambiguation are building estimates on incomplete information — and the gaps always show up during delivery.
What the numbers actually look like
The 67% overrun rate is a headline figure. Break it down by project type and it gets more specific:
| Project type | Avg. overrun | Primary cause |
|---|---|---|
| CMS migration | +31% | Content volume underestimation, integration gaps |
| E-commerce build | +44% | Integration complexity, checkout edge cases |
| Headless rebuild | +38% | API layer complexity, client-side rendering scope |
| Custom web application | +52% | Feature creep, requirement ambiguity |
| ERP/CRM integration | +61% | API documentation inaccuracy, data mapping gaps |
ERP integrations overrun by 61% on average. Not because agencies are bad at them — because the integration documentation is almost always wrong, and the actual API behaviour only becomes visible during development. The scope looked reasonable based on what was knowable at the time. The overrun was structural, not avoidable by working harder.
"The scope looked reasonable based on what was knowable at the time. The overrun was structural, not avoidable by working harder."
Why the standard fixes don't work
The industry's default responses to scoping failure are: more detailed statements of work, change control processes, and fixed-price contracts. These are all reasonable ideas that mostly don't solve the problem.
More detailed SOWs
A more detailed SOW captures more of what's known. It doesn't capture what isn't known yet. The 44% average overrun on e-commerce builds doesn't come from failing to specify the homepage design in enough detail — it comes from discovering mid-project that the payment provider's sandbox environment doesn't support multi-currency testing, or that the client's product catalogue has 47 edge cases their brief didn't mention. No amount of upfront documentation prevents discoveries.
Change control processes
Change control protects revenue on requests the client explicitly makes. It does nothing for scope that grows because of technical discoveries — integration complexity that only revealed itself in development, performance requirements that turn out to require a different architecture, security requirements that arrive late from the client's IT team. These aren't client change requests. They're scope gaps that were always there; they just weren't visible at estimating time.
Fixed-price contracts
Fixed-price contracts transfer overrun risk from the client to the agency. They don't reduce the probability of overrun — they just change who absorbs the cost. Agencies that run fixed-price projects either pad their estimates significantly (making them uncompetitive) or absorb the overrun internally (destroying margins). Neither outcome addresses the underlying problem.
What actually works: structured disambiguation and automated cross-checking
The agencies that consistently deliver within scope share two practices that most agencies don't have:
Structured brief disambiguation. Before any estimate is produced, the brief is systematically interrogated for the specific information classes that most commonly generate scope gaps: integration volume and API documentation status, content migration complexity, performance and compliance requirements, and third-party dependency status. This isn't a checkbox exercise — it's a disciplined process of converting intention into specification.
Cross-referenced estimation. Individual estimates are checked against comparable past projects — not informally ("this feels like the Acme project") but systematically, using actual delivery data. When an estimate deviates significantly from comparable past work, that deviation is a signal worth investigating before the SOW goes out.
These practices are hard to implement consistently with manual processes. A senior developer doing a scoping session under time pressure will miss disambiguation points. A PM cross-referencing estimates by memory will miss relevant comparables. The process requires either significant investment in tooling or acceptance that the checks will happen inconsistently.
Test Anvil on your last brief
Paste any client brief and see a structured scope with milestones, risk flags, and effort estimates in under 60 seconds. Anvil achieves 92% scope accuracy against actual delivery data.
Generate a Plan Free →The 92% accuracy benchmark — and what it takes to hit it
Anvil was benchmarked against 50 real agency briefs, comparing generated scopes to actual delivery outcomes. Across those projects, scope accuracy — milestone coverage matching actual delivery structure — was 92%, with an average budget variance of -8%.
That figure comes from three specific design decisions that aren't present in manual estimation:
Disambiguation before scoping. Anvil extracts implied scope from the brief before generating any estimates. Vague requirements ("integrate with our CRM") are disambiguated into specific scope items based on the integration type, volume, and documented complexity patterns. The estimate is built on what the project actually entails, not what the brief said.
Risk-adjusted estimates. Known risk classes — integration documentation quality, content volume assumptions, compliance requirements — are built into estimates as probability-weighted additions, not contingencies applied after the fact. An ERP integration is estimated with a 20–30% buffer embedded in the milestone, because that's what comparable projects actually take.
Compounding-aware scope modeling. When a scope change is identified, its downstream dependencies are traced and included. Adding a microsite isn't just "+40h" — it's +40h plus the template work, plus the content migration, plus the integration testing. The cascade is modeled, not ignored.
The practical implication for agency ops leads
If your agency is running a 30–60% overrun rate on digital projects, the problem is almost certainly in the scoping process, not the delivery process. Your developers and PMs aren't getting worse at execution — they're executing against scopes that were structurally incomplete from the start.
The fix isn't more process overhead or bigger SOWs. It's better information at the scoping stage — systematically extracted from the brief, cross-referenced against historical delivery data, and risk-adjusted for the specific complexity classes your project type carries.
The agencies running sub-10% budget variance aren't doing something heroic. They're doing something systematic.