Guide · Buying software

Why do software projects fail, and how do you rescue one?

Most software projects fail for organisational reasons: an unclear goal, too much scope, nobody making decisions, feedback that arrives too late and integrations that were underestimated. The code is rarely the first thing to go wrong. The warning signs show up early, and a project in trouble can usually be rescued by securing code and data, cutting back to a core and restarting with short deliveries. Here are the causes, the signs and the rescue plan.

12 min read · Updated 1 October 2026

Nine months into the project, the launch has moved three times. Every status meeting ends with the system being “90 % done”. Staff are still working in the same spreadsheets the system was meant to replace, and the invoices have reached twice the original budget. Nobody has done anything outright wrong, and yet the project is grinding to a halt. Many managers know this story, and it almost always follows the same pattern.

The good news is that the pattern can be recognised early. This guide covers the nine most common reasons software projects fail, the warning signs to watch from the first month, and a rescue plan for a project that has already stalled. The figures are examples; the causes are the ones we see in practice when companies come to us with a stalled project.

Why do software projects fail? The nine most common causes

Most causes are about goals, scope and collaboration. Only a few are purely technical.

Cause	What it looks like	What prevents it
Unclear goal	Nobody can say when the project is a success	One measurable goal, such as hours saved per week
Too much scope	Every wish goes into the first version	A first version with a clear core
No decision owner	Questions sit unanswered for weeks	One named person with authority on each side
Late feedback	Users see the system for the first time at launch	Working deliveries every two to four weeks
Underestimated integrations	ERP, accounting or login cause trouble at the end	Build and test integrations early
Wrong pricing model	Open-ended hours on a project with no fixed scope	Fixed price on a scoped version, or capped hours
Hand-offs	Design, development and running sit with different parties	One team responsible for the whole journey
Missing data	Old data has to move, but nobody has cleaned it	Data migration as its own task with an owner
No plan for running it	The system launches and nobody owns it afterwards	A running agreement and internal owner before you start

Notice how few of the causes are about programming. Bad code exists, and it creates technical debt that makes every change more expensive. Even the worst code is usually a symptom of something else: a scope that grew, a deadline that was squeezed or a team that changed along the way.

It usually starts with scope

The most common pattern is that the first version has to do everything. When sales, finance, warehouse and customer service each get their wishes in, the project becomes long, and none of the wishes is tested by real users until everything is done. That is why we recommend starting with a scoped first version, an MVP, and describing features as user stories, so it is clear who benefits from what. That also makes prioritising easy when the budget tightens.

Integrations are the biggest unknown

A system that has to talk to e-conomic, an ERP, MitID or a carrier depends on something neither party controls. The documentation may be thin, the subscription may lack API access, or the data may arrive in a different format than expected. When integrations are built last, the problems are discovered last. Build them in the first weeks, even if they only work with test data. Our guide what is an API explains what needs to be in place.

Which warning signs show a software project is failing?

You have not seen anything working for more than four weeks.
The status has been “nearly done” for several meetings in a row.
The launch date has moved more than once without a new, concrete plan.
The vendor’s questions have been sitting unanswered on your side for over a week.
Hours consumed are growing faster than the list of finished features.
New requests come in without anything else being taken out.
Integrations are “planned for the end”.
The people who built the beginning have been replaced.
You do not have access to the code or the test environment.
Nobody can say what happens on the day after launch.

“90 % done” is the most telling signal. In software the last ten per cent is often the hardest: error handling, edge cases, data migration, integrations and testing on real devices. When a project has been 90 % done for two months, it is typically because the hard parts were pushed to the end. Ask to see the specific features running, and ask for a list of what is missing.

What does a healthy software project look like compared with one in trouble?

Project in trouble

Status reports in text
Integrations built at the end
Scope grows every month
Decisions made in large meetings
The code sits only with the vendor

Healthy project

Working software every two to four weeks
Integrations tested in the first weeks
New requests swap places with old ones
One decision owner per side
The client has access to code and test environment

The same project, two trajectories.

It is worth noting that both columns can occur with agile and waterfall alike. The method matters less than the rhythm: short deliveries, early integrations and clear decisions. We have written more about how fixed price and agile development fit together in agile vs waterfall.

How do you rescue a software project that has stalled?

1. Pause and take stock

Put new requests on hold. Write down what was ordered, paid for and actually delivered.

2. Secure code, data and access

Get access to the repository, database, hosting, domain and app store accounts.

3. Get an independent review

Have another team review code, architecture and status and judge what can be reused.

4. Cut back to a core

Find the smallest version that can launch and create value for one user group.

5. Decide: repair, rebuild or switch

Use the review and the decision table below. Set a budget and a date.

6. Restart with short deliveries

Working software every two weeks, tested by real users, until the core is live.

The rescue plan in six steps. Step two comes before anything else that costs money.

Step two is what gives you freedom. Without access to the code you can neither get an independent review nor change vendor, and you are in a weak position in any negotiation. If you do not have access today, start by getting it; our guide to who owns the code has a checklist for exactly that situation.

Should you repair, rebuild or change vendor?

A simple decision table. Several rows can apply at once; the highest one that fits carries the most weight.

If	Then
You cannot get access to the code	Plan a rebuild, and secure the data first
The code is in a widely used technology and well structured	Repair and build on it, possibly with a new team
The core works, but the integrations fail	Fix the integrations first, then launch
Every small change takes weeks and creates new bugs	Rebuild the core, reuse design and data model
The vendor acknowledges the problem and has a concrete plan	Give one chance with a testable delivery within 2–4 weeks
The project started as a quick AI prototype	Assess security and structure before building on it

The last row has become more common. Many companies have had a quick prototype built with AI tools that works in a demo but lacks login, access control and tests. It can be an excellent starting point if it is treated as a prototype. Read from AI prototype to production. If the system is older and hard to change, see legacy system modernisation.

What can you do before the start to keep the project on track?

Write one measurable goal for the project, such as “halve the time spent invoicing”.
Define a first version that can launch within a few months.
Appoint one decision owner on your side with time and authority.
Choose the vendor with a fixed process and consistent criteria.
Agree on working deliveries every two to four weeks.
Plan integrations and data migration early in the project.
Get code, data and accounts written into your name.
Agree on running and ownership internally before you launch.

Point four is big enough that we wrote a whole guide on it: how to choose a software company, with a scoring table for comparing vendors. And when the proposals arrive, use red flags in a software quote to find the risks before they become yours.

What do we do at Ceptiv to keep projects on track?

Our way of working is built around the causes above. We give a fixed price on a defined scope, so there are no open-ended hours to run out of. Design and development happen in one senior team, with no hand-offs between departments. We use more than 40 pre-built integrations, including e-conomic, Dinero, MobilePay, PostNord, Penneo and MitID, so the most common unknowns are known in advance. And you follow progress in the client panel, where deliveries and decisions sit in one place.

Large solutions can be built in parts. For Vaskekonerne we made eight solutions in one circuit, from website and booking to operations. If you have a project that has stalled, describe the situation here. We assess what can be reused, and you get a written proposal for the way forward within 24 hours.

Questions about failing software projects

What is the most common reason software projects fail?

What we see most often is a scope that is too large and too unclear from the start. When every wish goes into the first version, the project becomes long, expensive and hard to test, and nobody sees anything working until it is too late to change direction. The best prevention is to define a first version that solves one concrete problem for one user group, launch it and build on the back of real usage.

How can you tell a software project is going wrong?

The clearest sign is that you have not seen anything working for more than four weeks. Other signs are status meetings where everything is “nearly done”, a launch date that moves more than once, questions from the vendor that sit unanswered on your side, and invoices growing faster than the features. One sign on its own is not a crisis. If you see three or more at the same time, stop and take stock.

Who is responsible when a software project fails?

Legally, it depends on the contract: what was agreed on scope, timeline, acceptance and the client’s own deliverables. In practice responsibility is almost always shared. The vendor must deliver what was agreed and raise problems in time, and the client must provide decisions, content and access to systems. Many projects stall because one side is waiting for the other. That is why both sides need a named person with the authority to decide.

Can we claim money back if the vendor fails to deliver?

You may be able to, but it depends on the contract and whether there is a material breach. It typically requires that you can document what was agreed, that you complained in time and that the vendor had the chance to remedy the problem. A dispute takes time and costs money on both sides. Talk to a lawyer before you act, and at the same time secure code, data and access so the business can keep running.

What does it cost to rescue a software project?

It depends on how much of the existing work can be reused. An independent review of the code and status typically takes from a few days to a couple of weeks. If the code can be repaired, the cost is often in the same range as the missing features. If the core has to be rebuilt, expect normal market prices for a comparable system. The most important thing is to hold back further spending on the same plan until you know what has actually been built.

Should we change vendor or give the current one another chance?

Give another chance if the vendor acknowledges the problem, can explain the cause and proposes a concrete plan with a testable delivery within two to four weeks. Change if you cannot get access to the code, if the explanations shift from meeting to meeting, or if the same deadline has been missed several times without a new plan. Whatever you choose: secure code, data and accounts first, so you are free to decide.

Want us to build it for you?

You get a fixed-price proposal within 24 hours.

Get an independent review of your project