DEV Community

Cover image for Software Project Cost Overruns: The Data
Dennis Vorobyov
Dennis Vorobyov

Posted on • Originally published at eltexsoft.com

Software Project Cost Overruns: The Data

McKinsey and the University of Oxford studied 5,400 large-scale IT projects. The average project ran 45% over budget, 7% over time, and delivered 56% less value than predicted. 17% of those projects became what the researchers called "black swans" — cost overruns of 200-400% that threatened the company's existence.

The Standish Group's CHAOS Report tells a similar story from a different angle: 66% of software projects experience cost overruns or schedule delays. Only 29% are completed on time and on budget. These numbers have barely improved in 30 years of tracking.

I have run custom software development projects for 11 years. Some came in on budget. Some did not. The difference was never the technology. It was always the process.

Why Projects Overrun

Fixed-bid contracts create incentives to cut corners

Fixed-bid sounds safe to the buyer. "We know exactly what we'll pay." In practice, it creates a zero-sum game. Every hour the vendor spends beyond the estimate comes out of their margin. So they cut: fewer tests, less documentation, junior developers instead of senior, shortcuts in architecture.

The result is a project that technically meets the spec but is fragile, poorly documented, and expensive to maintain. The buyer "saved" money on the build and then spends 2x maintaining a system that was built to hit a number, not to last.

We do not do fixed-bid. We work on monthly retainer. The client pays for senior engineering time. They see what we build every sprint. If priorities change, the work changes. There is no incentive to cut corners because there is no fixed scope to race toward.

Scope is a guess, not a fact

Every software project starts with a spec that is wrong. Not because the spec is bad. Because nobody can perfectly predict what a system needs to do before building it. Users behave differently than expected. Integrations have undocumented limitations. The market shifts.

McKinsey found that scope creep adds 20-40% to outsourced project costs. PMI's Pulse of the Profession reports that 52-55% of projects experience scope creep. This is not a failure of planning. It is a feature of software development. Requirements evolve as understanding deepens.

The projects that succeed are the ones that plan for scope evolution instead of pretending it will not happen. Sprint-based delivery with 2-week check-ins means the client sees working software every 14 days and can redirect based on reality, not the spec document from 4 months ago.

Junior engineers are slower and more expensive

The math looks obvious: a junior developer at $40/hour is cheaper than a senior developer at $80/hour. In practice, the junior developer takes 3x longer, produces code with 5x more defects, and requires senior oversight that is never budgeted.

A 2019 study published in IEEE Software found that experienced developers were 2-5x more productive than their less experienced peers on identical tasks. Not 20% more productive. 200-500%.

Our rate is $50-99/hour. Every engineer is senior. No juniors, no bench staffing, no bait-and-switch. The effective cost per delivered feature is lower because the work is done right the first time.

Nobody measures until it is too late

The McKinsey/Oxford study found that the worst overruns were in projects with infrequent checkpoints. Quarterly reviews meant 3 months could pass before anyone noticed the project was off track. By then, the cost of correction was enormous.

Sprint-based delivery fixes this. Every 2 weeks, the client sees: what was built, how much it cost, and what is planned next. If the project is trending over budget, the signal comes in week 2, not month 9.

The Black Swan Problem

17% of IT projects become black swans: 200-400% overruns. McKinsey describes these as projects that "can threaten the very existence of the company."

What makes a black swan? The research points to three factors: massive scope (multi-year, multi-system), poor governance (infrequent checkpoints, no executive sponsor), and technology risk (building with unproven tools).

The fix for all three is the same: make the project smaller. Break a 2-year initiative into 3-month deliverables. Deploy after each one. Get real user feedback. Adjust scope based on what you learn. A project that ships every 3 months cannot become a 400% overrun because the overrun is visible and correctable in real time.

HeyTutor started as a 3-month MVP. Nine years later, it is a marketplace with 10,000+ tutors and LAUSD as a client. But it was never a "2-year project." It was always a series of 2-week sprints, each one deliverable, each one reviewed with the founders.

What Prevents Overruns

Based on 11 years and 35+ projects:

Retainer, not fixed-bid. The client pays for engineering time and controls the priorities. No incentive to cut corners. No adversarial relationship when scope changes.

2-week sprints with deliverables. Every sprint produces working software that the client can see and test. Budget tracking is real-time, not quarterly.

Senior engineers only. The $50-99/hour rate buys engineers who have shipped similar projects before. They know the patterns, the pitfalls, and the shortcuts that are safe versus the ones that will cost you later.

Scope defined as outcomes, not features. "Reduce manual appraisal processing time by 50%" is a better scope than "build 47 screens." The first lets the team find the best solution. The second locks them into building screens whether or not those screens solve the problem.

CI/CD from day one. Our co-founder sets up automated deployment, testing, and staging environments before the first feature is built. This means we can ship any day, test any change, and demonstrate progress any time. Greek House went from releases every few months to same-day deploys because the infrastructure was right from the start.

The Budget Conversation

When a prospective client asks "how much will this cost?" the honest answer is: it depends on scope, and scope will change. What I can tell you is what it costs per month, what a team looks like, and what you should expect to see after 3 months, 6 months, 12 months.

An MVP with 2-3 senior engineers typically costs $40,000-$100,000 over 3-6 months. A mature product with 5-7 engineers costs $40,000-$70,000/month on retainer. These are real numbers from real projects, not ranges designed to cover every possible outcome.

The custom software cost guide has more detail on pricing by project type. The point here is different: the cost is predictable when the process is right. The overruns happen when the process is wrong.

Talk to us →

Last updated December 21, 2025

Older
Only 24% of Developers Are Happy at Work
Newer
Staff Augmentation vs Outsourcing: An Honest Comparison from 11 Years of Running Both

Top comments (0)