Software Project Failure Statistics (2026): 40+ Data Points Every Developer Should Know

Let us start with the numbers that get cited the most and for good reason. The software industry has a terrible track record when it comes to delivering projects successfully.

• 31% of software projects succeed (on time, on budget, with full scope). 50% are "challenged" and 19% fail outright. (Standish Group CHAOS Report, 2020)
• Only 16.2% of projects succeeded in the original 1994 Standish Group survey, while 31.1% were canceled before completion. (Standish Group, 1994)
• 52.7% of projects in 1994 ran 189% over their original cost estimate. Budget overruns were the norm, not the exception. (Standish Group, 1994)
• By 2012, the success rate improved to 37%, with 42% challenged and 21% failing. Progress, but still not great. (Standish Group CHAOS Manifesto, 2012)
• 66% of technology projects end in partial or total failure, based on analysis of 50,000 projects globally. (Standish Group CHAOS Report, 2020)
• Only 0.5% of IT projects meet all three success criteria (on time, on budget, delivering intended benefits). Just one in 200 projects. (McKinsey and University of Oxford)

That last stat from McKinsey deserves its own paragraph. Think about it. If you are working on a software project right now, there is a 99.5% chance it will miss at least one major target. Those are not good odds.

The good news is that the complete failure rate has dropped from 31.1% in 1994 to 19% in 2020. The bad news is that the "challenged" category, meaning projects that ship late, over budget, or with reduced scope, has actually grown.

If there is one variable that predicts project failure better than anything else, it is size. The data on this is overwhelming and consistent across every major study.

• Small projects achieve roughly 90% success rates. Large projects succeed less than 10% of the time. (Standish Group CHAOS Report, 2020)
• Large IT projects (budgets over $15 million) run 45% over budget and 7% over time, while delivering 56% less value than predicted. (McKinsey and University of Oxford)
• Each additional year a project runs increases cost overruns by 15%. Time is the enemy of project success. (McKinsey)
• One in six IT projects has a cost overrun of 200% on average. These are the "black swan" projects that can bankrupt departments. (Harvard Business Review)
• The most extreme case in one Oxford study saw a project hit nearly 700% cost overrun. (University of Oxford research, published in HBR)
• Large organizations fared worst in the original CHAOS report: only 9% of their projects succeeded, with 61.5% challenged and 29.5% canceled. (Standish Group, 1994)

The takeaway for developers is simple: if someone asks you to join a massive, multi-year project with a huge budget, understand that you are statistically walking into a failure. That does not mean you should refuse. It means you should push hard for breaking the work into smaller, independent deliverables.

The Standish Group has been saying this for 30 years. Small projects win. Break big projects into small ones. It is the single most effective strategy for improving your odds of success.

Software project failures are not just embarrassing. They are devastatingly expensive. The numbers are staggering.

• Failed IT projects cost the United States $50 to $150 billion annually in lost revenue and productivity. (Forbes, citing Gallup and HBR research)
• Organizations waste 10% of every dollar spent on projects due to poor project performance. That translates to roughly $122 million wasted for every $1 billion invested. (Project Management Institute, Pulse of the Profession)
• Projects that miss one or more success measures exceed budgets by 75% on average, overrun schedules by 46%, and generate 39% less value than predicted. (McKinsey)
• "Black swan" IT projects can see budget overruns between 200% and 400%. These are rare but catastrophic. (McKinsey and University of Oxford)
• Only 1 in 14 IT projects is delivered on time and on budget. (McKinsey)

Let me put this in terms that hit closer to home. If your company is spending $2 million on a software project, the expected overrun based on industry data means you should budget for $3.5 million. And there is a reasonable chance you will deliver something that provides 39% less business value than what was promised in the original pitch deck.

This is why experienced developers get nervous when they see scope documents that read like wish lists. Every feature added to a project increases its size, complexity, and likelihood of failure.

Understanding failure rates is useful. Understanding why projects fail is actionable. Here is what the data says about root causes.

• 37% of organizations cite inaccurate requirements as the primary reason for project failure. Getting requirements wrong is the number-one killer. (PMI Pulse of the Profession, 2014)
• 70% of digital transformation projects fail to achieve their objectives. The ambition outpaces the execution. (McKinsey)
• 75% of all IT projects fail due to errors in the set-up phase. The project is doomed before a single line of code is written. (BITKOM e.V.)
• Scope creep is one of the most prevalent causes of project failure according to PMI research, with poorly defined initial scope enabling uncontrolled growth. (PMI)
• High "decision latency" teams achieve only 18% project success rates, compared to 63% for teams that make decisions quickly. Slow decisions kill projects. (Standish Group CHAOS Report)

The pattern is clear. Most software projects do not fail because of bad code. They fail because of bad planning, bad requirements, bad decision-making, and bad scope management. The technical problems are usually symptoms, not causes.

This is why I always tell developers: your most important skill is not your programming language. It is your ability to ask the right questions before you start building. "What exactly are we building? Who is it for? How will we know when it is done? What is out of scope?" These questions save projects.

The methodology debate has been raging for decades. Here is what the data actually says about which approach delivers better results.

• Agile projects have a 42% success rate compared to 13% for Waterfall projects. That is more than triple the success rate. (Standish Group CHAOS Report)
• Agile projects average an 88.2% success rate across all four criteria, while Waterfall projects average only 47% success. (ResearchGate analysis of Standish data)
• Agile has a 64% success rate vs. 49% for Waterfall according to Ambysoft's IT Project Success Rates Survey. (Ambysoft, 2013)
• 71% of U.S. companies use Agile as of 2022. Adoption is widespread, though implementation quality varies enormously. (Zippia, cited in Forbes)
• 80% of federal government IT projects use Agile or iterative approaches. Even the government has caught on. (Deloitte)
• 31.5% of teams now use a hybrid approach blending Agile flexibility with traditional structure. (Project Management Institute)

The numbers are consistent across every study: Agile outperforms Waterfall. But here is the nuance that the statistics miss. "Agile" means very different things at different organizations. A team doing two-week sprints with daily standups, clear backlogs, and empowered product owners is doing Agile. A team doing "Agile" because management renamed their status meetings to "standups" is doing theater.

The methodology matters less than the principles behind it: small increments, fast feedback, clear priorities, empowered teams. Those principles work whether you call them Agile, Lean, or just "common sense."

If you think private sector failure rates are bad, government IT projects exist in their own category of catastrophe.

• Only 13% of major U.S. state and local IT projects succeed. (18F/U.S. Digital Service research)
• Only 13% of large federal IT procurements (over $6 million) succeed. (Belfer Center for Science and International Affairs, Harvard)
• The FBI's Virtual Case File project was abandoned in 2005 after spending $170 million with nothing to show for it. Poor architecture, untrained managers, and constantly changing requirements. (U.S. Government Accountability Office)
• HealthCare.gov's initial launch in 2013 cost over $2 billion and was plagued by crashes and failures. The project had managers expert in healthcare but lacking technical expertise. (Brookings Institution)
• 87% of U.S. government IT projects are classified as failed. (Standish Group, 2019 data on government projects)

Government projects fail at higher rates for predictable reasons: procurement processes that prioritize the lowest bidder over the best team, political interference in technical decisions, multi-year timelines that guarantee scope creep, and a culture that punishes honest status reporting.

For developers considering government contracting work, these numbers are essential context. You are not walking into a normal software project. You are walking into an environment where the structural forces actively work against success. That said, organizations like 18F and the U.S. Digital Service have shown that applying modern development practices can dramatically improve outcomes, even within government constraints.

Statistics tell the story in aggregate. These individual failures put a face on the numbers.

• FBI Virtual Case File: $170 million wasted. The FBI tried to modernize its case management system starting in 2000. After five years of changing requirements, poor architecture, and managers without technical training, the entire project was scrapped. (U.S. GAO)
• FoxMeyer Drug ERP Implementation: Company bankruptcy. A poorly implemented enterprise resource planning system led FoxMeyer Drug, a $5 billion wholesale drug distribution company, into bankruptcy in 1996. One bad software project killed a Fortune 500 company. (IEEE Spectrum)
• HealthCare.gov: Over $2 billion. The initial October 2013 launch crashed repeatedly, with only 6 people able to sign up on launch day. The project required a complete rescue effort. (Brookings Institution, Government Reports)
• British NHS National Programme for IT: $12 billion abandoned. Originally budgeted at $6 billion in 2002, costs ballooned to $12 billion before the project was dismantled in 2011. It was the largest civilian IT project failure in history. (UK National Audit Office)
• SAP implementation at Lidl: $580 million abandoned. The German grocery giant spent seven years trying to implement SAP before abandoning the project and reverting to its legacy system. (German press reports, 2018)

Every one of these failures shares common patterns: unclear requirements, scope that grew uncontrollably, poor communication between technical teams and business stakeholders, and unrealistic timelines set by people who were not doing the actual work.

As a developer, you cannot always prevent these disasters. But you can recognize the warning signs. When you see changing requirements every sprint, when stakeholders cannot agree on what "done" looks like, when the timeline was set before the team was even assembled, you are looking at the early stages of a project that will become a statistic.

Not all industries struggle equally with software projects. Some sectors have structural characteristics that make failure more likely.

• Healthcare IT projects have a particularly high failure rate. Complex regulatory requirements, integration with legacy systems, and life-safety concerns create compounding risk factors. (Multiple industry analyses)
• Financial services spend heavily on IT but face significant challenges. The average large bank runs hundreds of concurrent IT projects, creating resource conflicts and integration nightmares. (McKinsey)
• 55% to 75% of ERP implementations are unsuccessful. Enterprise resource planning projects combine massive scope with organizational change management, a recipe for failure. (TrueProject, citing Panorama Consulting)
• 70% of digital transformation projects do not achieve their objectives. The buzzword-heavy nature of "digital transformation" often masks a lack of clear, measurable goals. (McKinsey)
• A European analysis found 30% of projects succeed and 20% fail outright, with the remaining 50% classified as challenged. The pattern holds across geographies. (ResearchGate, European project analysis)

The industries with the worst track records share two characteristics: heavy regulation and legacy system dependencies. When you have to build new software that integrates with 30-year-old mainframes while complying with hundreds of pages of regulatory requirements, the complexity multiplies in ways that are genuinely difficult to manage.

The data does not just tell us why projects fail. It also reveals what successful projects have in common.

• Small projects succeed at roughly 90% vs. less than 10% for large projects. Size is the most powerful predictor of success. (Standish Group)
• Teams with low decision latency achieve 63% success rates compared to 18% for high-latency teams. Fast decisions beat perfect decisions. (Standish Group)
• Agile projects are 3x more likely to succeed than Waterfall projects. Iterative delivery with fast feedback loops dramatically improves outcomes. (Standish Group)
• User involvement is consistently cited as the top factor in project success in the Standish Group's research across 30 years of CHAOS reports. (Standish Group)
• Executive support is the second most cited success factor. Projects with engaged sponsors who remove blockers and make decisions quickly have dramatically better outcomes. (Standish Group, PMI)
• Clear, stable requirements reduce failure risk by 37%. Getting requirements right is the single most impactful thing a team can do. (PMI Pulse of the Profession)

None of these factors are about technology. Not one. The successful projects are not using a specific programming language or framework. They are small, fast, well-supported by leadership, close to their users, and clear about what they are building.

This is the most important insight in all of software project management. Technical excellence matters, but it is table stakes. The projects that succeed are the ones that get the human factors right: communication, scope, decisions, and support.

The rise of AI-powered development tools is creating a new variable in the project success equation. Here is what early data suggests.

• 85% of project managers believe AI has the potential to significantly improve project delivery. Optimism is high, but results are still emerging. (WifiTalents research)
• AI solution implementation in project management has grown 45% annually over the last three years. Adoption is accelerating rapidly. (WifiTalents)
• 35% of professionals believe IT projects will benefit most from AI compared to other sectors like healthcare, construction, and government. (Association for Project Management, 2022)

AI tools are most promising in the areas that cause the most failures: requirements analysis, risk prediction, and progress monitoring. If an AI system can flag scope creep early or identify unrealistic timelines before work begins, it could address root causes rather than symptoms.

But here is the caution: AI is also making it faster to write bad code. If the fundamental problems are bad requirements and poor communication, writing code faster just means you build the wrong thing faster. The tools matter less than the process.

You cannot control your organization's project management maturity overnight. But you can use these statistics to make better decisions and push for better practices.

Before joining a project, ask these questions:

• How big is this project in terms of timeline and budget? (Remember: small projects have 90% success rates, large ones below 10%)
• Are the requirements documented and stable, or are we "figuring it out as we go"?
• Does the project have executive sponsorship from someone who will make decisions quickly?
• Are we using iterative delivery, or is this a big-bang release after months of development?
• Is there a mechanism for user feedback during development?

During a project, watch for these red flags:

• Requirements changing every sprint without corresponding timeline adjustments
• Stakeholders who cannot agree on priorities
• No access to actual end users for feedback
• Timeline pressure that eliminates testing and code review
• The phrase "we will figure that out later" applied to architectural decisions

To improve your team's odds:

• Push for smaller, independent deliverables instead of monolithic releases
• Document requirements before writing code, even if it feels slow
• Build in regular checkpoints where stakeholders see working software
• Raise scope concerns early and loudly, backed by these statistics
• Track decisions and their rationale so the team avoids re-litigating resolved issues

The developers who understand why projects fail are the ones who can prevent it. That makes you more valuable than a developer who just writes great code.

Here are the most important statistics from this research, organized for quick reference.

Overall Failure Rates:

• 31% of software projects succeed (Standish Group, 2020)
• 66% of projects end in partial or total failure (Standish Group, 2020)
• 0.5% of projects meet all three success criteria (McKinsey)
• 19% of projects are canceled outright (Standish Group, 2020)

Cost of Failure:

• $50-$150 billion annual cost to U.S. economy (Forbes/HBR)
• 75% average budget overrun for challenged projects (McKinsey)
• 10% of every project dollar is wasted (PMI)
• 1 in 6 projects sees 200%+ cost overrun (HBR)

Size Matters:

• 90% success rate for small projects (Standish Group)
• Less than 10% success for large projects (Standish Group)
• 45% average budget overrun for projects over $15M (McKinsey)

Root Causes:

• 37% cite inaccurate requirements as primary failure cause (PMI)
• 75% fail due to set-up phase errors (BITKOM)
• 70% of digital transformations miss objectives (McKinsey)

Methodology Impact:

• Agile: 42% success rate (Standish Group)
• Waterfall: 13% success rate (Standish Group)
• Fast decision-making teams: 63% success (Standish Group)

The data paints a sobering picture. After 30 years of research, methodology revolutions, and billions of dollars in tooling investments, most software projects still do not fully succeed. The overall success rate has improved from 16% in 1994 to 31% in 2020, but that progress has been painfully slow.

The causes of failure have remained remarkably consistent over three decades: unclear requirements, excessive scope, poor decision-making, and projects that are simply too large. The solutions are equally consistent: build small, iterate fast, involve users, empower teams, and get executive support.

As a developer, these numbers are not a reason for despair. They are a competitive advantage. Most developers have no idea that 66% of projects fail. They do not know that small projects succeed at 9x the rate of large ones. They do not understand that requirements matter more than code quality.

You now have that knowledge. Use it. Push for smaller deliverables. Ask hard questions about scope and requirements. Flag risks early. Choose projects with clear goals and engaged stakeholders. Build your career on the projects that succeed, and learn to spot the ones that will not.

The software industry does not need more developers who can write clever code. It needs developers who understand why projects fail and have the courage to do something about it.