Why software projects go over budget
The tail risk behind the biggest software budget overruns
Most software projects don’t blow their budgets. But when they do, they can blow them by a staggering amount.
That’s what makes software cost risk so difficult to plan for.
A major 2026 study published in PMI’s peer-reviewed Project Management Journal analyzed 11,011 projects across 23 project types, including 5,360 IT projects. The median IT project actually landed on budget. But nearly one in five (18%) overran its budget by more than 50%. And among those projects, the average overrun was 453%.
Of all 23 project types studied, IT had the most extreme cost risk, worse than nuclear power plants, the Olympics, and even nuclear waste storage.
Researchers call this tail risk. It’s the possibility that a relatively small number of projects will experience outcomes far more extreme than the typical project. In software, that tail can be particularly costly.
And the exposure is growing. PMI’s Pulse of the Profession 2026 report found that more than half of all projects now qualify as complex, and that nearly a third of complex projects fail to deliver their full intended benefits, more than twice the rate for projects overall. Researchers call that long, fat tail of blowouts tail risk. We call it the reason Discovery phases exist.
So if most projects land near their estimates, why do a meaningful minority detonate, and how do you keep yours out of that group? After two decades of building software for organizations of every size, we can tell you: it’s almost never about bad developers. It’s about how risk gets priced — or doesn’t — before the first line of code is written.
Let’s dig into what actually drives overruns, and the risk management practices that prevent them.
The real reason isn’t “scope creep” — It’s fiction priced as fact
Scope creep gets blamed for everything, and it’s a convenient villain. Something changed! Not our fault! But here’s the pattern we’ve seen over and over: what looks like scope creep is often hidden scope — work that was always necessary but never made it into the estimate.
That “simple” login feature? It hides password resets, session management, account lockouts, SSO edge cases, and accessibility requirements. A one-line feature request routinely conceals ten distinct workstreams. When those surface mid-project, they get logged as “scope changes.” But the scope didn’t change. The estimate was incomplete.
The research backs this up. Flyvbjerg’s team identifies goal ambiguity and the sheer malleability of software as classic drivers of requirements volatility, and notes that IT is rarely built on a blank slate: new work has to be patched into poorly documented legacy systems, and the true cost of that integration is hard to see in advance. They compare it to surgery. You often don’t know what you’ll find until you’re in there.
Discovery is how you look before you cut. In our experience, projects that invest in it don’t necessarily see fewer changes; they see fewer surprises, because more of the true scope gets captured up front. If your budget covers the defined scope plus a cushion for creep, and half your “creep” is actually undiscovered original scope, you were underwater before kickoff.
The takeaway: a suspiciously clean estimate isn’t a good sign. It’s compressed risk waiting to detonate.
The psychology problem: We’re all optimists (and that’s expensive)
Daniel Kahneman won a Nobel Prize for showing how human judgment goes wrong under uncertainty, and his work with Amos Tversky gave us the planning fallacy: our tendency to underestimate the cost, time, and risk of our own plans while overestimating their benefits. Two forces are at work:
Optimism bias. Teams estimate the best-case path — the version where the API documentation is accurate, the legacy data is clean, and nobody gets pulled onto another priority. Reality never cooperates that politely.
Strategic misrepresentation. Estimates aren’t just predictions; they’re sales tools. Vendors lowball to win work. Internal champions lowball to get projects approved. Usually nobody lies, exactly, but every rounding decision rounds down. And sometimes it goes well beyond rounding. In February 2026, a Quebec public inquiry into the SAAQclic platform at the province’s public auto insurer concluded that officials made a “conscious effort” to conceal the project’s true price tag as it ran roughly $500 million over budget.
The antidote is reference class forecasting, built on Kahneman and Tversky’s idea of the “outside view.” Instead of asking “how long will our project take?” (the inside view), you ask “how long did similar projects actually take?” Your team’s bottom-up estimate says four months? Great. But if the last five projects of this type at this complexity took six, budget for six. The UK made the method mandatory for cost estimates on government-sponsored transport projects, Denmark quickly followed, and governments from Australia to Norway have applied it to individual projects. It isn’t magic. A 2025 systematic review found the evidence generally positive but cautioned that the method is only as good as the comparison set you choose. It still beats trusting the pitch.
You don’t need a megaproject database to apply it. You need honest records of your own past projects (the same review urges organizations that lack one to start building it) and the discipline to trust the pattern over the pitch.
The structural problem: Slow decisions cost more than bad ones
Here’s an overrun driver nobody puts in the post-mortem: decision latency.
A developer hits an ambiguity — should the export include archived records? — and needs an answer. If that answer takes three weeks, the team may spend that time working around the ambiguity, context-switching, or building something they’ll later have to redo.”It’s common, too: PMI’s 2026 research found that delays in stakeholder decision-making affected 34% of complex projects worldwide. The same report points to the antidote. High performers were more likely to align with their sponsors on what success looks like before execution begins (39% versus 30% of low performers).
Governance failures burn budget in three specific ways: decisions delayed until blockers compound, decisions made at the wrong level and later reversed, and decisions made without engineering input that produce requirements no one can actually build. Quebec’s SAAQclic inquiry is a cautionary tale here, too. The commission flagged weaknesses in project governance, vendor management, and internal escalation, and found that warning signs did reach decision-makers but weren’t always acted on.
The fix is unglamorous: name a decision-maker with real authority, give them a service-level agreement (48 hours for routine calls), and keep a decision log. Boring? Absolutely. Cheaper than landing in that 453% tail? Also absolutely.
The contract problem: Incentives eat estimates for breakfast
One of the least-discussed budget killers is the engagement model itself. A fixed bid on a vaguely defined scope doesn’t eliminate risk — it just hides it until change orders start arriving. Worse, some models quietly reward vendors for discovering scope creep rather than preventing it.
Ask any prospective development partner two questions:
- “How long is your typical discovery phase?” If the answer is “we can skip that” for a substantial project, they’re not uncovering enough to estimate honestly. Two weeks is a floor, not a luxury.
- “Show me an estimate with ranges.” A single-number estimate is a guess wearing a suit. Honest estimates come as low/high ranges with the assumptions behind them spelled out, because software estimation is probabilistic and anyone pretending otherwise is pricing hope. The research agrees: the 2025 forecasting review recommends replacing single-point estimates with ranges that communicate uncertainty to decision-makers.
(This is why our own estimates at Creed come as ranges tied to explicit assumptions. When an assumption breaks, we can point to exactly what changed and what it costs — no mystery invoices.)
The wrinkle today: AI changes the tools, not the fundamentals
AI is changing how software teams estimate, plan, and identify risk. Used well, it can make Discovery better. Give it a feature description and it can surface dependencies, edge cases, integration questions, and other assumptions worth investigating before development begins.
But AI doesn’t make uncertainty disappear. It can just make an uncertain estimate sound more certain.
That’s especially important when you’re using AI to model project risk. A simulation is only as useful as the assumptions behind it, and Flyvbjerg’s team warns that treating IT risk as a normal or near-normal distribution can dramatically underestimate the extreme outcomes we’re trying to protect against.
The best use of AI here isn’t to ask, “What will this project cost?” It’s to ask better questions before deciding what the project will cost.
AI can help teams uncover what’s missing. Experienced people still need to decide what matters, challenge the assumptions, and own the estimate.
The budget-protection playbook
Pulling it all together, the projects that stay on budget share a few habits.
- Make the unknowns visible early. Invest in real Discovery before committing to a number. The goal isn’t to eliminate uncertainty. It’s to uncover hidden scope and make the remaining uncertainty explicit.
- Estimate in ranges, not single numbers. Check those ranges against the actual outcomes of comparable past projects, not just the team’s optimism. Software estimates are probabilities, not promises.
- Fund the work in phases. Use go/no-go gates so a bad assumption costs one phase instead of the entire roadmap. It’s the same logic as the modular, “big built from small” approach Flyvbjerg’s team identifies as an antidote to IT’s extreme cost risk.
- Protect your contingency. Keep reserves separate and require sign-off to use them. Research recommends keeping contingency out of easy reach and reserving it for genuine risks, because buffers that are easy to spend get spent.
- Put a price on change. Every new request should come with a visible cost and schedule impact before anyone says yes.
- Give someone the authority to decide. Ambiguity is expensive. Name a decision-maker, give them a deadline, and don’t let unresolved questions quietly become development work.
None of this is exotic. That’s the point. Budget overruns feel like lightning strikes, but they’re weather patterns — predictable, measurable, and manageable if you respect them.
The bottom line
Software projects don’t go over budget because teams fail. They go over budget because uncertainty gets treated as a footnote when it’s actually the headline. The organizations that ship on budget aren’t luckier or smarter — they’ve simply stopped pretending that precision equals accuracy, and started managing risk as a first-class citizen of the project plan.
If you’re planning a build in the next year and the estimates you’re seeing feel a little too tidy, that’s your cue. Let’s pressure-test them together before the code does it for you.
Creed Interactive is a Twin Cities web development and digital agency that’s been helping organizations plan, build, and ship software that respects both users and budgets. Have a project in the “cautiously optimistic estimate” stage? Let’s talk.
Sources
Flyvbjerg, B., Budzier, A., Aaen, J., Keil, M., & Zottoli, M. (2026). “The Uniqueness of IT Cost Risk: A Cross-Group Comparison of 23 Project Types.” Project Management Journal, 57(1). https://journals.sagepub.com/doi/10.1177/87569728251340590
Project Management Institute (May 2026). Pulse of the Profession 2026: Driving Success in Complex Projects. https://www.pmi.org/learning/thought-leadership/driving-success-in-complex-projects
Project Management Institute (May 12, 2026). “Why Complex Projects Fail: Best Practices Are Not Enough, System Thinking Gives Your Team the Edge.” Press release. https://www.pmi.org/about/press-media/2026/pulse-why-complex-projects-fail-best-practices-are-not-enough-system-thinking
The Week (June 24, 2026). “Stakeholder decision delays hinder 47% of major projects in South Asia, PMI report finds.” https://www.theweek.in/news/biz-tech/2026/06/24/stakeholder-decision-delays-hinder-47percent-of-major-projects-in-south-asia-pmi-report-finds.html
Cantarelli, C. C., Davis, K., Pinto, J. K., & Turner, N. (2025). “Reference class forecasting: promises, problems, and a research agenda moving forward.” Production Planning & Control. https://doi.org/10.1080/09537287.2025.2578708
Recamara, J. (February 17, 2026). “Quebec auto insurer accused of hiding $500M IT cost overrun.” Insurance Business. https://www.insurancebusinessmag.com/ca/news/technology/quebec-auto-insurer-accused-of-hiding-500m-it-cost-overrun-565552.aspx
Capterra (March 17, 2026). “AI for Project Managers Is Reshaping PM Software Decisions.” https://www.capterra.com/resources/ai-for-project-managers/
IBM and Ponemon Institute (July 29, 2026). Cost of a Data Breach Report 2026. https://www.ibm.com/reports/data-breach (press release: https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average)