I’ll research current data on software and website project overruns before writing.Let me get data specifically on requirements problems and scope change as causes of failure.I have strong, well-sourced data. I’ll note the IBM defect-cost claim is disputed, so I’ll handle it carefully and lean on the more solid NASA and Carnegie Mellon figures. Now I’ll write the article.
The proposal that promises a number it can’t possibly know
A vendor hands you a proposal. It lists every page, every feature, every integration, and at the bottom sits a single confident figure: the project will cost exactly this much and take exactly this long. You feel reassured. You shouldn’t. That number is a guess wearing a suit.
Fixed scope assumes you already know everything you need to know before anyone has done the work of finding out. It assumes the requirements are complete, the stakeholders agree, the technical surprises don’t exist, and your understanding of what you want won’t shift the moment you see the first working version. None of those things are true at the start of a website project. Pretending they are is how budgets get burned.
The evidence here is not subtle. The latest CHAOS data from the Standish Group shows that only 31% of projects were “successful,” fully 50% were challenged, and 19% failed outright. Challenged means late, over budget, or short on the features that were promised. So the most likely outcome for any given project is not the clean delivery the proposal describes. It’s the messy middle where the original fixed scope quietly falls apart.
Why “fixed” almost never survives contact with reality
The problem isn’t that vendors are lazy or clients are difficult. The problem is structural. A website project is an exercise in discovering what you actually need, and discovery happens during the work, not before the contract is signed.
Requirements are the root of most of it. According to a study by Info-Tech Research Group, 50% of rework was a direct result of requirements issues. Think about what that means in practice. Half the wasted effort on the average project traces back not to bad code or weak design, but to the fact that nobody nailed down what was being built before they started building it. Rework is commonly associated with poor development quality, but in reality it is usually introduced much earlier, during the requirements and scoping stages. The root cause is rarely code; it is unclear, incomplete, or ambiguous requirements. Many budget overruns are not created during execution. They are built into the project foundation from the start.
A fixed-scope contract doesn’t fix any of this. It just locks the ambiguity in place and attaches a price to it. When the gaps surface, and they always surface, you end up in change-order negotiations with a vendor who is now incentivised to interpret every gap as out of scope. The fixed price you signed up for becomes the floor, not the ceiling.
The triangle nobody gets to cheat
Scope, cost, schedule, and quality are connected. Project success depends on balancing scope, cost, schedule, and quality. When one of these elements is compromised, pressure inevitably shifts to the others. A truly fixed scope at a truly fixed price and a truly fixed deadline is a promise that something else will give. Usually it’s quality, the part nobody can see until launch, or it’s the working relationship, which curdles into a fight over who owes what.
You can fix any two of those corners. Fixing all of them and pretending the fourth will look after itself is the fantasy in the title.
What the numbers say about pretending
The cost of getting requirements wrong compounds the longer it goes undetected. The most credible work on this is a NASA paper from 2004 that reviewed seven separate studies alongside its own projects. NASA’s experience was that a requirements error costs 8 times more to fix during design, 16 times more after it is coded, 21 times more after testing, and 29 times more after deployment. A misunderstanding that would have cost almost nothing to resolve in a planning conversation becomes a serious bill once it’s baked into a live site.
You’ll see a more dramatic version of this claim floating around the industry, the famous “100x more expensive in production” figure attributed to an IBM institute. Treat that one with caution. Investigation found the IBM Systems Sciences Institute was an internal training program, and no data was available to support the figures in the widely circulated chart. The direction of the effect is real and well supported. The precise multiplier passed around in slide decks often isn’t. That distinction matters, because a number you can’t defend is worse than no number at all.
The waste is not small in aggregate either. Hooks and Farry found that rework of errant requirements consumes 28 percent to 42 percent of a project’s development costs. When something close to a third of your budget is spent fixing decisions that were never properly made, the “fixed” price was always going to move.
And the bigger the project, the worse the odds. Standish data reveals that small projects achieve around 90% success rates while large projects succeed less than 10% of the time, and projects exceeding $10 million are more than ten times more likely to be cancelled than those under $1 million. A fixed-scope contract for a large, complex build is a bet against the house.
Who actually causes the overrun
It’s tempting to blame the developers. They’re rarely the problem. The damage is usually done in the room long before anyone writes code.
It’s the board member who saw a competitor’s flashy new site and demanded the team match it, with no brief and no budget conversation. It’s the marketing lead who signed off on a scope document they skimmed, then discovered three weeks in that the CRM integration everyone assumed was included was never mentioned. It’s the agency that deliberately under-scoped to win the pitch, knowing the change orders would make up the margin later. And it’s the executive sponsor who went quiet at the exact moment the team needed a fast decision.
That last one is more expensive than it sounds. The Standish Group’s later research centred on what they call decision latency, the idea that the speed at which a project’s open questions get answered is one of the strongest predictors of whether it lands well. A fixed-scope contract does nothing to make those decisions faster. If anything it makes them slower, because every decision now has contractual consequences and people stall.
The common thread across all of these is governance, not technology. The main culprits are poor requirements gathering, lack of executive sponsorship, misalignment between project goals and business strategy, inadequate communication, and scope creep. Most failures come from planning and governance issues, not technical execution.
The honest alternative: replace the gamble with a blueprint
If fixed scope is a fantasy, the answer is not to throw your hands up and accept open-ended billing. That just trades one bad deal for another. The answer is to do the discovery work before you commit the build budget, so that what you’re fixing is real instead of imagined.
In our experience at NexusBond, most project failures trace back to the moment a company commits money to a scope nobody has validated. So we flip the sequence. Instead of asking vendors to bid against a wishlist, we run structured discovery first and produce a blueprint: validated requirements, a realistic scope grounded in what’s technically true, and stakeholders who have actually agreed on what success looks like. Only then does the build get priced. The point is that the number means something because the work to earn it has already been done.
This isn’t an expensive luxury. It’s the cheapest insurance you’ll buy on the whole project. The Carnegie Mellon Software Engineering Institute recommends allocating 8 to 13% of project budgets to requirements engineering activities, though industry surveys show most organisations only spend 3 to 5%. Most companies under-invest in the one phase that prevents the most waste, then act surprised when the build overruns. Carnegie Mellon research indicates that every dollar invested in improving requirements processes returns between $3.30 and $7.50 in reduced maintenance costs and rework.
What a blueprint-first approach actually fixes
When you do discovery properly before committing, several things change at once:
- The scope is real. You’ve interrogated the integrations, the content migration, the edge cases, the things that usually hide until week six. They’re on the table while they’re still cheap to address.
- Stakeholders have already argued. The disagreement between marketing, sales, and the CEO about what the homepage is for happens in discovery, not in the middle of the build when changing direction costs real money.
- You can compare vendors on substance. Once requirements are validated, a quote is a quote for the same thing. You stop comparing apples to vapour.
- The price you agree is defensible. Both sides know what’s included because both sides watched it get defined. Change orders become rare and legitimate rather than constant and contentious.
This is what we mean by clarity before commitment. You’re not buying a website on faith. You’re buying it knowing what you’re buying.
Agile isn’t a licence to wander
Some teams react to all of this by swinging to the opposite extreme: no scope at all, just keep building and we’ll figure it out. That’s not the answer either. Open-ended iteration without a defined outcome is how projects drift for eighteen months and still launch something nobody’s happy with.
The Standish Group’s own findings point toward delivering software in smaller pieces, early and often, rather than in one big delivery at the end. Their research indicates that smaller time frames, with delivery of software components early and often, increase the success rate, through an iterative process of design, prototype, develop, test, and deploy small elements. This engages the user earlier, gives each component an owner, sets expectations realistically, and gives each component a clear and precise statement of objectives.
Notice the phrase “clear and precise statement of objectives.” Iteration works when it’s pointed at a defined target. The blueprint gives you that target. The iterative build gives you the flexibility to adapt as you learn. Those two things are partners, not opposites. What burns budgets is the contract that pretends adaptation won’t happen, and the free-for-all that pretends direction doesn’t matter.
What to do this week
If you’re about to commission a website redesign, a new build, or a platform migration, stop before you ask anyone for a fixed price. Do these things first.
- Write down what you think the project includes, then list everything you’re assuming. The integrations, the content sources, who signs off, what “done” means. The assumptions are where the overruns live. Naming them now costs you an afternoon. Discovering them in month three costs you far more, as the NASA figures make plain.
- Get your decision-makers in one room and force the disagreement out early. If your CEO and your marketing lead don’t agree on what the site is for, find that out before a vendor is on the clock, not after.
- Treat any vendor offering a precise fixed price for a vague scope as a warning sign. A confident number attached to an undefined project isn’t reassurance. It’s a future argument with a date stamp on it.
- Budget for discovery as a distinct phase. If Carnegie Mellon’s research holds, the money you spend validating requirements is the highest-return spend on the whole project.
If you want a clear-eyed read on your own situation before you commit any budget, you can book your free discovery call and we’ll walk through where your project is most exposed.
Fixed scope feels safe because a single number is easier to approve than an honest conversation about uncertainty. But the number doesn’t make the uncertainty go away. It just hides it until the invoice arrives. Do the discovery first, fix what’s actually knowable, and stay flexible about the rest. That’s not a compromise. That’s the only version of “fixed” that survives contact with a real project.
Ready to get started?
