Why Software Projects Fail: 8 Causes & How to Avoid Them

Software projects fail far more often because of decisions than because of code. Standish Group CHAOS data shows only 31% of IT projects finish on time, on budget and with the agreed scope, while roughly 19% are cancelled or never used. The most common trigger is unclear scope and inaccurate requirements gathering.

Those numbers have barely moved in two decades. Tooling improved, teams went agile, cloud infrastructure got cheap — and the same mistakes keep repeating. This guide walks through where a software project actually derails, which early signals it sends, and how to rescue one that already stalled. Every figure here comes from a primary source you can open and check.

Table of Contents

• How Often Do Software Projects Fail?
• Cause 1: Scope Is Never Pinned Down
• Cause 2: Requirements Come From the Boardroom, Not the Floor
• Cause 3: The Wrong Vendor and a Thin Contract
• Cause 4: Everything Is Crammed Into One Phase
• Cause 5: Nobody Owns the Decisions
• Cause 6: No Tests, No Acceptance Criteria
• Cause 7: Data Migration Is Left to the Last Week
• Cause 8: Launch Day Is Mistaken for the Finish Line
• How to Rescue a Stalled Project
• Seven Monthly Checkpoints
• Frequently Asked Questions

How Often Do Software Projects Fail?

"Failure" is not one outcome. Research separates three: the project that hits its goals, the project that ships late or with features cut, and the project that never ships at all. Knowing the difference matters, because yours will most likely land in the middle bucket.

At company scale, a "challenged" project looks like this: ten months instead of six, nine of the fourteen planned modules, and a change order on top of the original budget. Nobody calls that a failure and nobody celebrates it either. The cost, though, lands close to a cancellation — you get back neither the money nor the year.

A comparative study published in PM World Journal in January 2026 tracked Standish Group CHAOS data across a decade. The picture is remarkably static (PM World Journal).

Averages mislead you here. Bent Flyvbjerg and Alexander Budzier at the University of Oxford studied 1,471 IT projects and found an average cost overrun of 27%. The tail is what should worry you: one in six projects was a "black swan" with an average cost overrun of 200% and a schedule overrun of almost 70% (Flyvbjerg and Budzier, Harvard Business Review). Their wider dataset shows IT projects miss the initial cost estimate by more than 10% in eight cases out of ten.

So the real risk is not a mild slip. The real risk is that one project in six triples its budget — and that tail has killed companies. The same research documents Levi Strauss taking a $192.5 million charge against earnings over an SAP migration that started with a budget under $5 million, and Kmart's $1.4 billion modernisation effort feeding into its 2002 bankruptcy filing.

Project Management Institute puts a number on the everyday waste too: 9.9% of every dollar is lost to poor project performance, or $99 million for every $1 billion invested (PMI Pulse of the Profession 2018).

PMI also asked practitioners which factors primarily caused their failed projects. Respondents picked up to three.

Not one of the top eight is a technology choice. They are all scope, goals, communication and governance. Software project failure is, for the most part, a management-discipline problem.

One more note before the list. Post-mortems love to blame the stack — "we picked the wrong framework", "that database didn't suit us". Those sentences feel better because they move the blame to a tool. But technology never appears near the top of the primary research. The eight causes below are the practical version of what does.

Cause 1: Scope Is Never Pinned Down

Scope creep is a project growing without approval or paperwork. PMI's 2018 research found scope creep in 52% of projects completed in the previous 12 months, up from 43% five years earlier. The high performers PMI labels champions held the rate at 33%; underperformers hit 69%.

Scope creep never arrives as one big decision. It arrives as "let's add this too, it's half an hour of work". Fifteen individually harmless requests turn your project into a different project within three months — and none of them reach the schedule or the budget. By the end nobody remembers the original plan, so everyone blames the delay on the development team.

There is a second trap: the garnish the developers add themselves. An elaborate interface nobody asked for, a report screen nobody will open. The literature calls it gold plating. The result is the same — days spent, no value delivered.

The most expensive form of creep is the "small" integration request. Hooking up the accounting system, a shipping carrier API, a payment provider webhook. Each one gets asked for in a single sentence and takes weeks. Projects that leave integrations out of the first scope document almost always blow the schedule.

The fix: Write two lists before anyone writes code. One is what you will deliver; the other is what you explicitly will not deliver in this phase. The second list is worth more than the first. After that, answer one question for every new request: which deliverable does this delay, and what does it cost? The question set in our website design brief guide works just as well as a software project brief.

Cause 2: Requirements Come From the Boardroom, Not the Floor

Look again at PMI's top three: priorities changed (39%), objectives changed (37%), requirements gathered inaccurately (35%). Technology is nowhere on the list. The problem in this kind of software project is not that the software was built badly — it is that the wrong thing was built.

Here is how it plays out. The managing director and the IT lead describe the requirements. The people who will actually use the software are the warehouse clerk and the field crew. The system ships, and the clerk goes back to the old spreadsheet. The software works; nobody uses it. Technically a success, commercially a zero.

The second common mistake is refusing to accept that the client does not yet know exactly what they want. Most companies enter a project without having written their own process down. That is why the analysis phase is not overhead — it is insurance.

Requirements also need measurable output. "Order entry will get easier" is a wish, not a target. "Entering one order drops from four minutes to one minute" is a target, and you can write a test for it.

The fix: Run at least one hour with each real user, for each module. Watch how they work today rather than asking them to describe it. Then answer in writing, for every screen: who opens this, how many times a day, on which device? Drop any screen without an answer.

Cause 3: The Wrong Vendor and a Thin Contract

Companies that compare proposals on price alone pay the difference twice. On a software project, a low bid usually reflects narrow scope, a junior team or no testing budget. If the contract has no acceptance criteria, "done" stays negotiable and every handover becomes a new round of bargaining.

The costliest omission is source code ownership. If the code does not sit in a repository under your name, you lose the software project the day you part ways with the vendor. The next team starts from zero and your entire spend is written off. One contract clause solves it; the absence of that clause gets paid for in months.

Team transparency matters just as much. The senior people who pitched may not be the people who write the code. Ask for the roles and seniority of the assigned team in writing. A fourth risk is vendor size: a one-person shop looks fast and cheap until that person gets ill and the project stops. Confirm up front that more than one developer knows the codebase.

The fix: Get four things into the contract — the deliverables list, acceptance criteria, the change-request process, and transfer of source code ownership. Our guide to choosing a software development company lists the criteria to score, and app source code ownership covers the legal side of the handover.

Cause 4: Everything Is Crammed Into One Phase

A big project is a big risk. In the Oxford dataset the average project budget was $167 million and the largest $33 billion; the bigger the scale, the fatter the tail. The same logic holds at small-business scale: one 18-month monolithic software project is far more fragile than six three-month phases.

The worst part of a single-phase plan is the feedback delay. Discover a bad assumption in month 14 and you rewrite the 14 months of work built on top of it. Ship a working release every three months and you find the same mistake in month three, with only three months at risk.

Long projects accumulate a second problem: the business need changes while you build. It is no accident that "change in the organisation's priorities" tops PMI's failure list. In 18 months the company's agenda moves too.

Phasing also buys you budget control. At the end of each phase you decide again whether to continue. If phase one disappoints, you have risked one sixth of the budget rather than all of it.

The fix: Point phase one at the single process that either earns the money or wastes the most time. Everything else waits. We set out the steps in our MVP guide. To see how phasing changes the number, try different scope scenarios in the website cost calculator.

Cause 5: Nobody Owns the Decisions

Poor communication accounts for 29% of PMI's failure causes and inadequate sponsor support for 26%. Both come from the same root: the software project has no owner. A different manager joins the weekly call each week, last week's decision gets reopened, and the team designs the same screen a third time.

When decision ownership scatters, the development team waits. A waiting team either guesses or drifts onto another project, and both damage the work. Worse, bad news stops travelling upward — problems stay inside the team for months.

Birmingham City Council's Oracle programme is the public record of exactly that. Problems were not adequately disclosed to the council's cross-party structures for around 13 months. A project first estimated at £19 million is now projected to reach £216.5 million by April 2026, and the £69 million of savings budgeted for 2023/24 were written off entirely (The Register).

The fix: Name one decision owner and define their authority in writing. Hold a fixed 30-minute weekly meeting. Write the decisions down as bullets at the end of the call and circulate them; a verbal agreement evaporates in three weeks. You also need a process owner alongside the decision owner — someone from the team that will use the system daily and can answer questions. Loading both roles onto one person stalls most small-company projects. And reward the team that brings bad news early instead of punishing them.

Cause 6: No Tests, No Acceptance Criteria

The later you find a defect, the more it costs. In the study NIST commissioned from the Research Triangle Institute, identifying and correcting defects accounts for roughly 80% of development costs, and more than half of all bugs are not found until late, "downstream" stages (NIST report). The same work put the annual cost of inadequate software testing infrastructure to the US economy at $59.5 billion.

Another measurement shows the size of the bill. CISQ's 2022 report put the annual cost of poor software quality in the US at $2.41 trillion, with accumulated technical debt at roughly $1.52 trillion (CISQ). Technical debt is simply the shortcut you take today coming back with interest.

You also cannot test a project that has no acceptance criteria. If "does the order screen work?" has no measurable answer, every handover turns into an argument. And companies that leave testing entirely to the developer never validate their own business rules.

The fix: Write a one-sentence acceptance criterion for every feature: "When the clerk scans a barcode, stock decrements within two seconds." Run user acceptance testing with real data, real users, and at least two weeks before launch. Split the defect list in two: what blocks launch and what does not. Watch regressions as well — old screens break quietly as new features land, and re-running your core workflows end to end at each phase boundary is the cheapest way to catch that.

Cause 7: Data Migration Is Left to the Last Week

Data migration is the silent killer of software projects. Records the old system tolerated get rejected by the new one. Duplicate customer cards, blank tax IDs, stock quantities entered in different units — all of it surfaces on migration day. The team stops building and starts cleaning, and the schedule slips by a month.

In the Birmingham case, customisations in the first implementation disrupted bank reconciliation. The council could not produce auditable accounts for 18 months and eventually re-implemented the system "out of the box". Heavy customisation always inflates migration risk. Rather than bending a packaged product past its limits, purpose-built software is often the more predictable route.

A second risk is leaving "which data moves?" unanswered. Migrating ten years of history is both expensive and risky. For most companies, two years of transactions plus all active master records is enough; the rest can stay in the old system as an archive.

The fix: Start data cleansing in month one, and do it in the legacy system. Plan at least two rehearsal migrations — one into a staging environment, one a week before go-live. Keep a written rollback plan for the first week. If you are moving off an existing platform, the staged approach in our legacy software modernization guide will make it easier.

Cause 8: Launch Day Is Mistaken for the Finish Line

Launch is the middle of a software project, not the end. Skip training and users fall back on old habits. Software nobody adopts produces the same outcome as software nobody wrote: the process still runs in a spreadsheet. Three months later management says "the system didn't work", when the system was never actually tried.

AI projects are harsher still. RAND's 2024 report notes that, by some estimates, more than 80% of AI projects fail — twice the rate of IT projects that do not involve AI. RAND interviewed 65 data scientists and engineers, and the most common root cause was misunderstanding the problem to be solved (RAND). Between 70% and 85% of generative AI projects never get past proof of concept.

The fix: Add three items to the launch plan: role-based training, a 30-day support window, and an adoption metric. Track weekly active users and what share of the target process actually runs in the system. If month two is still under 50%, the problem is the workflow, not the software. The fastest way to lift adoption is to grow an internal "super user" — people ask a colleague the question they are too embarrassed to ask the vendor. Pick that person before launch. Our software maintenance agreement guide explains how to define support scope in the contract.

What ties all eight causes together is this: every one of them is visible before the project starts or in its first few months. None is a technical surprise that appears in the final week. Companies that spot them early fix them; companies that spot them late pay for them.

How to Rescue a Stalled Project

A half-finished software project is not automatically scrap. Three questions decide it: do you have the source code, is the data model sound, and is the remaining work cheaper than a rewrite? Three yeses usually mean continuing is both faster and cheaper.

Here is the sequence we run:

1. Code and infrastructure inventory. Repository access, libraries in use, server configuration and third-party service keys, all in one list.
2. Technical assessment report. Architecture, data model, test coverage and security gaps scored separately. This takes five to ten working days.
3. Decision table. Three options priced side by side with timelines: continue, partially rewrite, rebuild from scratch.
4. Data recovery plan. If the existing database maps onto the new structure, months of entered data survive.
5. A short first phase. The first delivery after a takeover should not exceed four to six weeks. Trust comes back with a working release.

The technical assessment report stays with you even if you decide not to continue. It is your strongest card in any vendor conversation, because you finally know what you are buying. Be careful reading takeover proposals, though: "let's rewrite it" is sometimes the right answer, but it is always the most profitable one. Read that report with an eye independent of whoever would do the work.

Missing documentation is the biggest drag during a takeover. Most stalled projects have no written architecture document — the knowledge sits in the departed developer's head. Try to get a short knowledge-transfer session into the handover agreement. Two hours of conversation beats weeks of reading code.

The most common takeover mistake is blaming the previous team and deleting everything. Keeping the modules that work rescues the budget and the morale together. Our web software development service starts every takeover with that assessment report; we do not write code against unmeasured risk.

Seven Monthly Checkpoints

Review these seven software project checkpoints at the start of every month. If you cannot answer yes to all of them, your software project is signalling.

1. Is scope written down? Are the deliverables list and the out-of-scope list in the same document?
2. Have you seen a working build in the last 30 days? Not a screenshot — something clickable.
3. Do change requests get logged with a price and a timeline?
4. Is there one decision owner, and do they attend the meetings?
5. Are acceptance criteria written for every feature?
6. Has a migration rehearsal been run?
7. Can you access the source code today?

The seventh matters most. If the other six go wrong but you hold the code, you can still rescue the project. If you do not hold the code, perfect scores on the other six leave you with zero negotiating power.

Send this list to your vendor as well. A good team will show you it already tracks most of these and will flag the gaps itself. A team that gets defensive and tells you "that's not how we work" has just given you your first warning sign.

Frequently Asked Questions

What percentage of software projects fail?

Standish Group CHAOS data indicates roughly 19% of IT projects are cancelled outright or never used. Another 50% ship late, over budget or with scope cut. Only about 31% finish on time, on budget and with the agreed feature set.

What is the single most common cause of software project failure?

In PMI's research, 39% of failed projects saw the organisation's priorities change, 37% saw project objectives change, and 35% involved inaccurate requirements gathering. All three share a root: no written answer to "what" and "why" at the start. Technology choice does not rank near the top.

How do I stop scope creep?

List the out-of-scope work in writing and log every new request with its price and schedule impact. In PMI's data, the high performers PMI labels champions saw creep in 33% of projects versus 69% for underperformers. The difference comes from a written change process, not from a tool.

Can a stalled software project be rescued?

If you hold the source code and the database, most projects can be saved. A five-to-ten-day technical assessment is usually enough to decide; it prices continuing, partial rewrite and a full rebuild side by side. Without code access, a rewrite is normally the cheaper route.

How do I avoid going over budget?

Break the work into three-month phases and close each one with a working release. The Oxford study found an average overrun of 27%, but one project in six overran by 200% — and that tail concentrates in long single-phase projects. Phasing lets you find mistakes early and correct them cheaply.

Which clauses must a software development contract include?

Four are non-negotiable: the deliverables list, acceptance criteria per feature, the change-request process, and transfer of source code ownership. Maintenance scope, response times, the seniority of the assigned team and post-launch support terms deserve their own sections too.

Do AI projects fail more often than other software projects?

Yes. RAND's 2024 report notes that by some estimates more than 80% of AI projects fail, twice the rate of IT projects without AI. The leading root cause is not the technology but a misunderstanding of the problem being solved. Between 70% and 85% of generative AI pilots never clear proof of concept.

Is it worth budgeting for a discovery phase?

Yes. Discovery is the cheapest insurance in the project: correcting a wrong assumption in a document takes a day, correcting it in code takes a month. Teams that allocate 10% to 15% of total budget to discovery and scope work hold their schedule estimates noticeably better.

Most software project failures are decided before anyone writes code. Put scope in writing, talk to the people who will actually use the system, define acceptance criteria, and get code ownership into the contract — those four move you to the good side of the statistics. None of them is a technical skill; all of them are discipline.

One last point: the statistics are not your destiny. In the same PMI research, organisations with high value-delivery maturity finish 64% of projects on time and 67% within budget, against 36% and 43% for low-maturity organisations. The gap comes from process discipline rather than from budget or technology.

If you have a stalled project on your hands, or you want to get the scope right before starting a new one, let's review where things stand together. Get in touch and we will put together a technical assessment of your project.