By ByteBot
IEEE Spectrum published a sobering analysis on November 23, 2025: Despite global IT spending tripling from $1.7 trillion to $5.6 trillion since 2005, software project success rates haven’t improved in two decades. The United States alone has burned through $10+ trillion on failed IT projects since 2005. Annual costs hit $1.81 trillion for operational failures and $260 billion for development failures, according to Consortium for Information & Software Quality (CISQ) data. This isn’t gradual improvement hitting obstacles. This is stagnation at trillion-dollar scale.
Robert Charette, the IEEE Spectrum contributing editor behind the analysis, frames it bluntly in the print edition: “The Trillion-Dollar Cost of IT’s Willful Ignorance.” The industry knows projects are failing. The data proves success rates haven’t budged. Yet organizations keep assuming “we’ll get better eventually” without addressing root causes. For developers, this failure ecosystem affects every project choice and career decision.
The Spending Paradox: More Money, Same Failure Rate
IT spending increased 3.3x in constant dollars over 20 years. Success rates stayed flat at 35-48% depending on measurement criteria. That means 66% of technology projects experience partial or total failure – approximately $3.8 trillion in annual global IT spending failing to achieve intended outcomes.
The CISQ report breaks down US failures: $1.81 trillion annually on operational failures (production systems that malfunction) plus $260 billion on development failures (projects cancelled or failing to meet requirements). For perspective, $1.81 trillion exceeds the entire $778 billion US defense budget.
This contradicts the fundamental industry assumption that spending on better tools, methodologies, and infrastructure would naturally improve outcomes. Twenty years of evidence says it doesn’t work that way.
Phoenix Payroll: The $3.6 Billion Case Study
Canada’s Phoenix payroll system exemplifies how failure persists. Launched in 2016 with a $300 million budget, it has cost taxpayers $3.6+ billion over nine years. The system still has 300,000+ outstanding errors affecting 425,000 employees. Within the first two years, over 20,000 employees were overpaid, underpaid, or not paid at all. As of 2024, 213,000 transactions remain more than one year overdue.
Canada is now planning to ditch Phoenix entirely and build a replacement system. The pattern repeats: organizations continue funding failing projects rather than accepting sunk costs, then attempt rewrites that often fail worse than the original. Phoenix represents the “too big to fail, too broken to fix” trap that ensnares major IT initiatives across industries.
This isn’t an outlier. It’s a case study in how systemic failure works. The project had unclear requirements, poor stakeholder communication, aggressive timelines, and complex legacy system integration – the exact red flags that predict failure. Yet it proceeded anyway, burning $3.6 billion before acknowledging defeat.
Why Software Projects Keep Failing: Requirements, Communication, Complexity
Research consistently identifies three primary causes: poor requirements (39% of failures), communication breakdown (57% of failing projects), and scope creep (78% of projects). Methodology doesn’t fix these problems. Agile projects show a 65% failure rate compared to Waterfall’s 49%, suggesting the issue runs deeper than process.
The requirements failure pattern is straightforward: 39% of projects fail due to poor requirements gathering, incomplete specifications, or lack of user involvement. Info-Tech Research Group found 50% of rework results directly from requirements issues. Yet the industry continues treating requirements as secondary to methodology debates about Agile versus Waterfall.
Communication failure compounds the problem. 57% of failing projects suffer from inadequate planning and communication breakdown between stakeholders. Technical problems are solvable. Communication failures doom projects. The industry invests heavily in technical infrastructure while underfunding the stakeholder management and communication structures that actually determine success.
Scope creep affects 78% of projects – not because developers can’t control scope, but because organizations lack the discipline to enforce boundaries. The “we’ll figure it out as we go” mindset popular in Agile circles becomes an excuse to skip requirements definition and let scope drift indefinitely.
The Legacy Maintenance Death Spiral
Organizations spend 70-75% of IT budgets maintaining legacy systems – $520 billion annually in the United States alone. This leaves only 25-30% for new development. Underfunded new projects are more likely to fail, becoming tomorrow’s legacy systems that consume even more maintenance budget.
The cycle compounds: today’s failures become tomorrow’s legacy burden. Failed projects still need support despite never delivering intended value. Organizations can’t abandon them because business operations depend on whatever partial functionality exists. The budget drain increases while innovation capacity decreases.
For developers, this explains why so many projects feel chronically underfunded. They are. Most IT budget goes to keeping broken systems running, not building new ones properly. Recognize this pattern and avoid projects where legacy maintenance consumes more than 60% of available resources – they’re structurally doomed.
What Developers Should Actually Do
You can’t fix the industry’s systemic failure problem. You can make informed decisions about which projects to join, when to raise red flags, and when to walk away. Warning sign recognition protects careers.
Red flags (high failure risk):
- “We’ll figure out requirements as we go” – signals 39% failure cause
- “Just build what the CEO wants” – lacks user involvement
- Aggressive timelines without contingency buffers – empirically leads to 189% cost overruns
- Legacy integration with undocumented code – trapped in the maintenance death spiral
- Organization pattern of failed projects or frequent leadership churn – systemic dysfunction
Green flags (lower failure risk):
- Documented, validated requirements with actual end-user input
- Clear stakeholder communication structure with escalation paths
- Realistic timelines with 30%+ contingency buffers
- Explicit scope boundaries with formal change control process
- Organization track record of completing similar projects successfully
Career protection requires recognizing doomed projects early. Working on a Phoenix payroll-scale failure damages your reputation, burns you out, and wastes years of your professional life. Learn the warning signs. Demand process changes or leave early. Your career has more value than any single project.
The Uncomfortable Truth About IT Project Failure
The industry assumes “we’ll get better eventually” with zero supporting evidence. Twenty years of data proves we haven’t improved despite tripling spending. Success rates remain stuck at 35-48% regardless of methodology, tooling, or investment level.
Charette’s “willful ignorance” framing captures it: the industry knows what’s failing and why, but continues selling methodology snake oil (Agile evangelism despite 65% failure rates) while ignoring root causes. Organizations refuse to cut losses on failing projects, creating Phoenix payroll-style disasters. Developers continue joining doomed projects without recognizing the warning signs.
The path forward requires honesty about success rates, investing in requirements engineering and communication infrastructure, accepting sunk costs and cancelling failing projects early, and reducing the legacy maintenance burden through aggressive decommissioning. None of this happens if the industry maintains its willful ignorance.
For now, developers need data-driven decision-making, not hope-based assumptions. Recognize the patterns. Protect your career. The trillion-dollar failure tax isn’t going away until the industry stops ignoring what the data has been saying for two decades.
