Why software projects fail: 5 reasons that keep repeating

In 2005, the world spent US$1.7 trillion a year on information technology. By 2025, in inflation-adjusted dollars, that number reached US$5.6 trillion. According to a report by Robert N. Charette in IEEE Spectrum, published on November 23, 2025, the success rate of software projects didn't visibly improve over that period.

Charette has tracked software failures for two decades. His conclusion is uncomfortable: projects don't fail because of new or hard technology. They fail for the same old reasons. In his words, “hope is not a methodology.”

The size of the problem

The report's examples come from government agencies and large companies, but the logic applies to any founder.

• The Canadian government's Phoenix payroll system was budgeted at CA$310 million and went live in 2016. It has already cost more than CA$5.1 billion. About 70% of the 430,000 public servants had paycheck errors over nine years.
• Minnesota's vehicle licensing system was planned at US$41 million and canceled in 2019, after costing US$100 million.
• Lidl abandoned a €500 million ERP after three years and went back to its old system.
• In the US, CISQ estimated the cost of software development failures at US$260 billion in 2022 alone.

None of these projects set out to fail. All of them had a budget, a team and a schedule.

The 5 reasons your product never went live

IEEE Spectrum lists more than ten causes. We grouped the ones that show up most in founders' digital products into five.

1. The goal was never written down

Charette points to “unrealistic or unarticulated goals” as a recurring cause. In a digital product, it looks like this: everyone agrees the app needs to “solve the customer's problem,” but nobody wrote down which problem, for whom and how to measure it. Without a written goal, every meeting changes direction.

2. Scope grows with no owner

Scope creep is the best-known item on the list. Each new feature seems small. Added up, they push the launch back by months. The sign is simple: if nobody has the authority to say “that goes to version 2”, the scope will keep growing until the money runs out. That's why it pays to learn to cut scope to fit the date.

3. Timeline and cost were lowballed

The report cites “overly optimistic cost and schedule assumptions,” like cutting testing and skipping pilots. In the Phoenix case, the project was budgeted at less than 60% of the vendor's proposal. When the number fits the wish and not the work, the gap shows up later, with interest.

4. Testing was left for the end

“Inadequate testing” is on the list. In a small product, testing is usually the first thing sacrificed when the deadline tightens. The result is a launch that breaks on the first day of real use and burns the trust of your first customers, who are the hardest to win.

5. Nobody owns the decisions

Charette talks about a lack of accountability for management decisions and internal politics that hide problems. For a founder with an outside vendor, this looks familiar: the studio says the delay is the scope change's fault, the founder says it's the studio's fault, and the product stays offline. It's the picture of a late software project.

The trap of thinking your case is different

One point in the report deserves attention: the “uniqueness trap,” when managers dismiss lessons from past failures because they think their project is one of a kind. Charette sums it up: repeating the same mistakes and expecting a different result isn't learning.

Every founder thinks their product is different. The product may be. The way to make it fail almost never is.

What this means for you

Before you start or restart a project, answer in writing:

1. What's the goal of the first version, in one sentence and with a number?
2. What's explicitly left out?
3. What's the date, and who can change it?
4. When and how will the product be tested with real people?
5. Who owns the result, on your side and on the vendor's?

If any answer is “we'll figure it out later,” you already know where the project will stall.

How we do it at the Studio

We start with discovery. Only after it do we quote, and the price is fixed. The deadline is written into the contract, and scope is cut to fit that date, not the other way around. That's how LCX, a travel company operating in more than 10 countries in South America, replaced one system per country with a single system, live in 29 days.

After launch, every system ships with an AI agent that runs daily, flags issues, suggests improvements and checks that the data makes sense. It's testing that doesn't end when the project does.

If you want to get a system or SaaS off the ground without repeating these five reasons, that's exactly the work of our custom system and SaaS development service.