What Are The Warning Signs Of A Failing Software Project?

If you are reading this, you probably already know. Something about the last three status calls did not add up.

Software projects rarely collapse in one moment. They drift, one reassuring update at a time, until the gap between what has been reported and what exists is too big to close.

The scale of the problem is not in doubt. DSIT’s State of Digital Government review found that only 9% of central government digital and data programmes were rated Green, and that they were 60% more likely to be rated Red than the wider project portfolio.

The signs below are deliberately physical. Each is something you can check this week without a technical background, and none of them can be talked around on a call.

Why Do Software Projects Fail Quietly Instead of All at Once?

Projects fail quietly because the reporting and the working software drift apart. Status is produced by people, builds are produced by machines, and only one of those two has a reason to be optimistic.

How Reporting and Reality Drift Apart

It starts with a sprint that slips and a summary that rounds up rather than down. By month four the summary is the only version of the project anyone has looked at.

Nobody lies. Each individual update is defensible, and the accumulated picture is fiction.

The antidote is boring and effective: measure delivery rather than effort. The GOV.UK Service Standard is built around working software in front of users, which is exactly the test a drifting project cannot pass.

Scale Does Not Protect You

Big organisations with real governance get this wrong too. The National Audit Office reported in November 2025 that NS&I’s business transformation programme had risen from an estimated £1.7bn in 2020 to around £3bn, with completion pushed back four years to March 2028.

The pattern repeats across the portfolio. Of 189 projects in the NISTA Major Projects Annual Report 2025-26, 34 were rated Red at 31 March 2026, roughly one in five.

The historical cost anchor still holds as well. A McKinsey and University of Oxford study of more than 5,400 large IT projects found average overruns of 45% on budget while delivering 56% less value than forecast.

Related: What Are the Signs That a Software Project Is in Trouble?

Which Red Flags Mean a Software Project Is Genuinely in Trouble?

The signs worth acting on all have physical evidence behind them: repository access, a running build, a reachable test environment, a bug trend, and written acceptance criteria. Everything else is atmosphere.

Ten signs follow, in the order they usually appear. Score yourself as you read, because the next section turns the count into a decision.

1. You Still Do Not Have Access to the Source Control Repository

If you are paying for code you cannot see, you do not know it exists.

Every professional team uses Git or something very like it, and giving a client read access takes about two minutes. A supplier who delays it for weeks is usually protecting the commit history, not the intellectual property.

That history shows who has worked on your project and whether last month’s invoices match last month’s commits.

2. The Demo Only Ever Shows the Same Screen

Ten sprints in, if you are still being shown the dashboard, there is probably only a dashboard.

Demos are curated by definition. A healthy one moves around the product and gets driven by whoever asks the awkward question.

So ask to click. If it is suddenly easier for them to share their screen, the rest of the product is not in a state you are allowed to see.

3. It Has Been “90% Done” for Three Months

Percentage complete is an opinion. Once it stalls above 85%, it usually means the remaining work was never sized.

The last tenth is integration, error handling, edge cases, performance and deployment. It is the hardest part, which is why it swallows schedules whole.

Ask a different question. What is left, itemised, with an owner and a date on each line?

4. There Is No Test Environment You Can Reach Yourself

If the only way to see the software is a scheduled call, the software may only work on one developer’s laptop.

A staging environment with a URL and a login is standard and costs very little. It is the difference between reported progress and progress you can check yourself.

• No staging URL after the first month of build.
• The environment is “temporarily down” on the day of every review.
• Test data that never changes between demos.

5. Velocity Gets Reported, but a Working Build Never Appears

Story points are an internal planning tool. They can climb steadily while nothing ships.

Watch for the burndown that looks healthy every fortnight while the release date moves every quarter. Points measure effort, and deployments measure delivery.

The number worth tracking is how often something reaches an environment you can open. If that is zero, velocity is decoration.

6. The Team Keeps Changing and Nobody Tells You

Silent turnover is one of the most reliable predictors of a date that is about to slip again.

New names on calls, no handover mentioned, questions you answered in month one asked again in month five. Each replacement costs weeks of ramp-up at full rate.

Usually it means your project has become the one people get moved off, not onto.

7. Bugs Open Faster Than They Close

A defect backlog that grows while features keep shipping means quality has been traded for the appearance of progress.

Ask for the open bug count at the end of each of the last six sprints. The trend matters far more than the number, and any tracker produces it in a minute.

A SonarQube scan shows the same thing from the code side within hours: duplication, untested paths and a maintainability rating.

8. Nobody Can Show You Written Acceptance Criteria

If “done” is not defined in writing, every disagreement becomes a negotiation, and you will lose most of them.

Acceptance criteria are the plain sentences saying what a feature must do to count as finished. Without them, change requests appear for work you assumed was in scope, which is usually a requirements capture failure rather than a coding one.

For the vocabulary, ISO/IEC 25010:2023 sets out nine product quality characteristics including functional suitability, performance efficiency, reliability, security and maintainability.

9. There Is No Handover Documentation and Nobody Seems Worried

A team that cannot hand over is a team you cannot leave. That is a commercial position, not an engineering one.

Ask what a new developer would need on day one: a README, environment setup steps, architecture notes, and credentials held somewhere other than one person’s machine.

If handover documentation would take a month to produce, that month already sits inside your project, unbudgeted. Suppliers who follow documented development practices produce it as they go rather than as an exit tax.

10. Every Problem Is Explained as Technical Debt, With No Plan Attached

Technical debt is a real constraint. Used as a permanent excuse, it makes slow delivery sound principled.

McKinsey’s research put tech debt at 20% to 40% of the value of an entire technology estate before depreciation, so a large number on its own is normal.

Debt with no register, no owner and no repayment plan is not normal. Ask which three items hurt most and what clearing them would take, which is where a legacy modernisation conversation properly starts.

How Serious Is Each Warning Sign?

Severity reflects what the sign implies rather than how annoying it is. Critical means the deliverable itself may not exist in the form you have been told.

Warning sign	Severity	What it usually means underneath
No repository access	Critical	The work may not exist, or ownership is being held over you
Same screen in every demo	High	One thin slice built, very little behind it
“90% done” for months	High	The remaining work has never been estimated
No reachable test environment	Critical	Nothing deployable exists yet
Velocity reported, no build	High	Effort is measured, delivery is not
Unannounced team changes	Medium	Your project has been quietly deprioritised
Bug count rising each sprint	High	Quality traded for visible features
No written acceptance criteria	Medium	Scope disputes will land on your side
No handover documentation	Critical	Lock-in, deliberate or accidental
Technical debt as a blanket excuse	Medium	Explanations in place of an engineering plan

How Do You Score Your Own Project in Ten Minutes?

Score 3 for each Critical sign present, 2 for each High and 1 for each Medium. A total of 6 or more means commission an independent audit now, and any single Critical sign on its own justifies one.

No competitor gives you a number, and a number is what gets a board to act. Fill this in before your next status call.

Score	Band	What it means	What to do this month
0 – 2	Healthy	Normal delivery friction on a live project	Nothing beyond keeping access and the bug trend in view
3 – 5	Watch	Drift has started and reporting is ahead of reality	Put the four evidence requests in writing, set a dated test
6 – 9	Intervene	The gap between reported and actual is now material	Commission an independent code audit, review the contract
10 – 14	Critical	You cannot verify that a working system exists	Audit immediately, stop milestone payments pending evidence
15+	Exit planning	Access, deployability and documentation are all absent	Secure IP and assets, plan a takeover or a rebuild

How to Read Your Score

The bands are deliberately blunt. A project scoring 4 is recoverable by conversation, and a project scoring 12 is recoverable only by evidence.

Weight the Critical signs above the total. Two Criticals and nothing else is worse than five Mediums, because access and deployability are the things that cannot be faked.

What Changes at Each Band

In the Watch band you are gathering evidence while continuing to pay. In the Intervene band you are gathering evidence while deciding whether to keep paying.

By the Critical band the question has changed from whether the project is late to whether it exists, which is the point at which a code rescue assessment stops being premature.

What Can You Check Without a Technical Background?

Almost all of it. Whether you can open the software yourself, whether the demo changes, whether names on the call change, and whether the invoice trend matches the progress trend are all observable without reading a line of code.

Most articles on this subject assume you know what a sprint burndown is. You do not need to.

Things You Can Observe on a Call

• Who talks. If the account manager answers technical questions and the engineer stays silent, the engineer may be new.
• What is not shown. Ask to see a part of the product that was not on the agenda.
• How specific the excuses are. “Integration issues” three weeks running is a pattern, not a reason.
• Whether anyone commits to a date in writing afterwards.

Things You Can Check on an Invoice

Money leaves a trail that status reports do not. Line the last six invoices up against the last six status reports and look for divergence.

What you compare	Healthy pattern	Warning pattern
Invoiced days vs commits in the repository	Broadly proportional month to month	Steady billing, thinning commit history
Named people billed vs people on calls	Same names, stable over months	Roles billed generically, names keep changing
Spend to date vs features accepted	Both curves rise together	Spend rises, acceptance flatlines
Change requests raised	Occasional, tied to real scope changes	Frequent, covering work you assumed was included
Milestone payments vs milestone evidence	Payment follows demonstrated acceptance	Payment follows elapsed time only

The last row is the one worth checking first. If your contract ties payment to elapsed time rather than acceptance, you have no bargaining position, and what should be in a software development contract explains what to change at renewal.

Could the Problem Be on Your Side?

Sometimes, and it is worth ten minutes of honesty before you escalate. Absent decision makers, unowned requirements and late sign-off cause the same symptoms as a weak supplier, and they are cheaper to fix.

No competitor asks this question, because most of them are selling rescue services. It changes the answer often enough to be worth asking.

The Sponsor-Side Causes That Repeat

• No single decision maker, so every question waits for a meeting that keeps moving.
• Requirements that were never written down, then treated as obvious when they were missed.
• Sign-off taking three weeks while the team is billing full time.
• Scope added verbally and never priced, then resented when the date moves.
• Nobody available to answer questions from a distributed team in a different timezone.

How to Tell the Difference

Look at where the waiting happens. If the supplier’s questions sit unanswered in your inbox for a week at a time, the bottleneck has your name on it.

If the answers go back within a day and the work still does not appear, it does not. Either way, a written project delivery plan makes the bottleneck visible instead of arguable.

Related: The Importance of Having an Actionable Software Project Plan

What Should You Do Once You Have Spotted the Warning Signs?

Move from feeling to evidence on a four-week clock: request access in writing, commission an independent code audit, check your contract and escrow position, then set a dated delivery test before you make any contractual decision.

Sequence matters. Acting on week four’s information in week one is how buyers end up in a dispute they cannot evidence.

When	What you do	What a healthy supplier does	What tells you to escalate
Week 1	Email four requests: repo read access, staging URL and login, open bug list, itemised remaining scope with dates	Sends three within a day and explains the fourth	Silence, or a meeting offered instead of the artefacts
Week 2	Commission an independent code audit	Cooperates and offers a walkthrough	Refuses access, or delays until after the next invoice
Week 3	Review contract, IP position, payment triggers and escrow	Confirms IP assigns on payment	IP assigns on completion, undefined, or held back
Week 4	Set a two-week evidence test with three named outcomes	Agrees in writing and hits two of three	Renegotiates the test rather than attempting it
Week 6	Decide: continue, renegotiate, take over, or exit	You are choosing between good options	You are choosing how to limit the damage

Week One: Put the Requests in Writing

Email beats a call. Ask for read access to the repository, a staging URL and login, the open bug list, and the itemised remaining scope, with a date against each.

The response is the diagnostic. A team that is behind but honest sends most of it within a day and tells you why the rest is late.

Week Two: Commission an Independent Code Audit

A code audit answers the question you cannot answer yourself: is there a real system in there. It covers architecture, test coverage, security exposure and how safely a new team could change things.

A narrow code-only audit of a mid-sized codebase typically takes one to three weeks. A fuller technical due diligence engagement costs more because it covers team, process, licensing and compliance as well as the code.

Against a build that has consumed six figures, either is cheap certainty, and technical due diligence costs sets out what each scope actually buys.

Ask for the security exposure to be in scope rather than assumed. A software security assessment often finds the issues that would have surfaced later as an incident.

If the system holds personal or payment data, get that reviewed by people who do it for a living. Application security work is a different discipline from general code review, and a failing project is usually weakest exactly there.

Week Three: Check Your Contract and Your Escrow Position

Find out who owns the intellectual property, what happens to it on termination, and whether payment is tied to acceptance or elapsed time. The Intellectual Property Office guidance is a useful primer if the contract language is unfamiliar.

If you hold a software escrow agreement, this is when it earns its fee. Providers publish their release conditions, typically insolvency, sustained breach of maintenance obligations or discontinuation of the service.

Verified escrow, where the deposit is tested to confirm it actually builds, is worth the extra cost. An unverified deposit can turn out to be a zip file nobody can compile.

Week Four: Set a Dated Evidence Test

Pick three things that must be demonstrably working in fourteen days, define what working means in writing, and say the decision on continuing depends on it.

• One feature deployed to staging that you can use unaided.
• The open bug count flat or falling across the fortnight.
• A written remaining-scope list with dates and owners against each line.

Talk to us about a code rescue assessment

What Are Your Options Besides Hiring a Rescue Firm?

Five: renegotiate with the current supplier, bring in independent oversight, insource the work, hand it to a takeover team, or stop and salvage the assets. Rescue firms rarely mention the first three, and two of them are cheaper.

Most articles on this topic are written by companies selling option four. Here is the honest comparison.

Option	Typical cost	Time to effect	When it fits
Renegotiate scope and terms	Nil to low	2 to 4 weeks	The team is competent, the plan was wrong
Independent oversight or fractional CTO	£3k to £12k a month	1 to 2 weeks	Delivery is real but unmanaged, and you cannot judge it
Insource with a hire or contractor	£40k to £90k a year	6 to 12 weeks	The work continues indefinitely and you want the knowledge
Takeover by a new supplier	Audit plus rebuild of the weak parts	3 to 8 weeks to productive	The code is real, the relationship is not
Stop and salvage	Exit costs plus asset recovery	2 to 6 weeks	No repository, no environments, no documentation

Renegotiate Before You Replace

Changing supplier costs three to eight weeks of ramp-up before anything ships. If the team can actually build and the problem is management, buying management is far cheaper than buying a new team.

That is the case for a fractional CTO, who can hold the supplier to evidence weekly without you having to learn what a pull request is.

When Walking Away Is the Cheapest Option

Sunk cost is not a reason to continue, because that money is gone under every option. The only question is which route reaches working software fastest from where you stand today.

If an audit shows no tests, no environments and no original developers, a rebuild against a clear specification usually beats an archaeology project. A structured software project takeover should tell you which of those two you are looking at before anyone quotes.

Related: How to Save a Failing Software Project

How Do You Work Out Whether to Rescue or Rebuild?

Compare three numbers: cost to complete with the current team, cost to take over and finish, and cost to rebuild the same scope from scratch. Spend to date belongs in none of them.

Most projects are recoverable when the code is real and the failure is a management failure. Stop when the codebase would take longer to understand and repair than to rebuild.

The Three Numbers That Decide It

Signal	Points to rescue	Points to rebuild
Repository	Exists with a genuine multi-month commit history	Absent, or the history starts last week
People	Someone who wrote the core code is still available	Every original developer has gone, nothing documented
Architecture	Ordinary and adequate, the process was the problem	Cannot support requirements you already have
Tests and pipeline	Automated tests exist, even partial ones	No tests, no environments, no build pipeline
Supplier behaviour	Will agree to an independent audit and handover	Refuses access or blocks handover
Cost comparison	Takeover cost well under a rebuild	Takeover estimate within 20% of a rebuild

If the takeover estimate lands within about 20% of a clean rebuild, rebuild. The rebuild comes with tests, documentation and a team who understand it.

Partial Rescue Is Usually the Answer

It is rarely all or nothing. A common outcome is that the data model and back end are sound while the front end is unsalvageable.

A takeover team should tell you which parts survive before quoting. Anyone who offers to rescue your project without reading the code first is a new supplier with the old supplier’s habits, which is also most of what choosing a good software development company comes down to.

Recovered projects do exist and they look ordinary afterwards. Our work with Composite Legal Expenses is the sort of outcome a stalled build reaches once someone owns the delivery.

What a Clean Exit Looks Like

Even when you are stopping, exit properly. Get the repository transferred to an account you control, take copies of environments and credentials, and collect whatever documentation exists before the final invoice is settled.

Your bargaining position disappears the moment the last payment clears. The same discipline is what keeps the next engagement out of trouble, whether you go in-house or outsource the build.

Then write down what you would do differently. Most repeat failures trace back to the same two causes, and mitigating outsourcing risk covers both.

Related Guides

Related: How to Save a Failing Software Project

Related: What Are the Signs That a Software Project Is in Trouble?

Related: Software Technical Due Diligence Costs Explained

Related: What Should Be in a Software Development Contract?

Related: What Is Legacy Software Modernisation?

Related: What Are the Stages of the Software Development Life Cycle?

Frequently Asked Questions