When to Audit a Failing Software Project?

When should you audit your software project, and when is it too late?

Nobody wakes up one morning and decides their software project has failed. It happens in small steps. A sprint slips by a week, which seems fine. The next demo gets pushed because of “integration issues.” The agency asks for a bit more budget to cover scope that was always meant to be included. Each delay has a reasonable explanation, and that is exactly the problem.

By the time most founders call in an outside team, they have usually suspected something was wrong for three or four months. They waited because asking for an audit felt like an accusation, or because the vendor kept promising the next release would fix things, or because there was simply no time to stop and look. We hear some version of “I should have done this in the spring” on most first calls.

This post is about timing. It covers the signals that mean you should get an independent look at your project now, what the research says about how fast the cost of waiting grows, and the harder question underneath it all: is there a point where a project can’t be saved, and how would you know if you’d reached it?

What the research says about waiting

The numbers on software overruns are not kind. A McKinsey study with the University of Oxford looked at more than 5,400 IT projects and found that large ones ran 45% over budget on average while delivering 56% less value than planned. About 17% went so badly that they could threaten the company itself, with cost overruns of 200% to 400%. The detail that matters most for this post is quieter: every extra year a project was planned to run added roughly 15% to its overrun. Time in trouble is not neutral. It compounds.

Bent Flyvbjerg and Alexander Budzier found something similar in their study of 1,471 IT projects. The average overrun was 27%, which sounds survivable. But roughly one project in six blew up badly, with cost overruns around 200% and schedules nearly 70% late. Software has unusually fat tails. Most projects slip a bit, and a few slip catastrophically, and from the inside the two look the same for longer than anyone would like.

The cost of fixing a problem also rises the longer it sits. You may have seen the claim that a bug costs 100 times more to fix in production than in design, credited to an IBM study. That figure is shakier than its popularity suggests: researchers traced it to old internal training notes, not a published study. Better evidence still points the same way, just less dramatically. Barry Boehm and Victor Basili’s review of defect research put the ratio near 100 to 1 for large critical systems and closer to 5 to 1 for small, noncritical ones. They also found that teams spend 40% to 50% of their effort on avoidable rework. For a startup, 5 to 1 is the honest anchor, and it is plenty. A problem that costs one week to fix now costs five weeks once it is buried under six months of features.

NASA measured the same effect in its own projects, and its figures show the shape of the curve even if the multipliers are higher than a typical startup will see.

Messy code also slows every fix that follows. A 2022 study of 39 codebases by Adam Tornhill and Markus Borg found that low quality code had about 15 times more defects, and issues in it took 124% longer to resolve. That is the mechanism behind the slow sprints founders notice: the team is not getting lazier, the code is getting harder to change.

One honest gap. There is no reliable research on how long failing projects typically run before someone steps in, and almost nothing on startups specifically. What follows on timing comes from what we see in rescue work, and we will say so where it does.

When it is high time to audit

The earliest warning signs are almost never technical. When Leon Kappelman and colleagues asked experienced IT project managers which signs best predicted failure, none of the top 17 were about code. They were about people and process: scope nobody wrote down, no real change control, no milestones, and early delays that never made it into a revised schedule. The code problems come later, as a result.

That is useful, because it means a founder who can’t read a pull request can still spot trouble. Here are the moments when we think an independent look stops being optional.

You missed a deliverable in the first tenth of the schedule

Kappelman’s panel singled this out as one of the few signs that shows up early enough to act on. A team that misses its first real milestone is rarely just unlucky. Usually the estimate was wrong or the scope was unclear, and both of those get more expensive every week they go unfixed.

The schedule slipped and nobody updated the plan

One late sprint is normal. The danger sign is a launch date that stays the same on paper while the work behind it falls further behind. Project managers use a simple ratio for this, work completed against work planned, and common practice treats a slip past 10% as a concern and past 20% as serious. You don’t need the formula. If the project is a fifth behind where it should be, it is time.

The remaining work would have to go impossibly fast

This is the most useful number we know of, and it is easy to work out. Take the work still left, the time still left, and ask how much faster than the current pace the team would need to go to hit the date. Walt Lipke tested this on 25 projects and found that once the required speedup passed about 10%, hitting the original target became unlikely. Teams almost never speed up in the second half of a troubled project. They slow down, because they are now fixing the first half too.

Key people left after kickoff

Another early sign from the same research. When the lead developer or the person who designed the architecture leaves, the knowledge leaves with them. If the vendor has quietly rotated its senior people off your project, you should know what state they left it in.

Before you raise money or sell

Investors increasingly run technical due diligence before a round, looking at code quality, security and how dependent the product is on one or two people. Finding a problem yourself three months before the data room opens is a fix. Having an investor find it is a negotiation, and not one you will enjoy.

Before launch, before scaling, and when you change vendors

PMI’s recovery literature notes that projects most often reveal their trouble near the end, which is the strongest argument for a review before launch. We would add two more from our own work. Audit before you double the team, because adding developers to a confused codebase multiplies the confusion. And audit when you take a product over from another agency, before the new team builds on top of whatever was left behind.

If two of these are true at once, don’t wait for a third. An audit at this stage usually takes one to two weeks and gives you a written answer. Waiting gives you more of the same, at a higher price.

When is it too late to recover?

Rarely as early as founders fear, and often later than they admit. That second part is where the research gets uncomfortable.

Why teams keep going too long

Mark Keil, Joan Mann and Arun Rai studied escalation in IT projects, meaning projects that keep getting money and time after they have clearly gone wrong. They estimated that 30% to 40% of IT projects show some escalation. Only 23% of escalated projects ended up successful, against 84% of the others, and their average budget overrun was 156% compared with 18%. Escalation lasted 21 months on average.

The strongest predictor was not sunk cost, which is what most people would guess. It was the feeling of being nearly finished. Teams that believed they were close to done were far more likely to keep pouring money in, followed by teams that hid bad news from whoever was paying. Anyone who has heard “we’re 90% there” for three months in a row knows that feeling.

Personal responsibility makes it worse. In Barry Staw’s classic 1976 experiment, people who had personally made a losing decision put more extra money into it than people who inherited the same decision. For a founder who picked the agency and defended the choice to the board, that is worth sitting with.

What “too late” looks like in public

The big government failures are useful precisely because they were audited afterwards. Queensland Health’s payroll system started as a $98 million plan and ended up costing more than $1.2 billion, with around 1,000 staff needed to pay 80,000 employees. Canada’s Phoenix pay system went live despite known defects after its pilot was cancelled, and its costs climbed from CAN$310 million to CAN$850 million, with up to another CAN$1 billion to fix. In both cases the warning signs were visible long before launch. Nobody with the authority to stop acted on them.

Healthcare.gov is the counterexample, and a slightly hopeful one. The site failed badly at its October 2013 launch, yet a rescue team got it working within months. The GAO’s review shows what the delay cost: the main contractor’s order grew from $56 million to more than $209 million, and the agency had considered acting on its concerns in August 2013 before the launch date won. The system was recoverable. Recovering it after launch was just far more expensive than it needed to be.

Signs a project is past saving

No study gives a clean line here, so this part comes from our own rescue work. A project, or more often one part of it, is usually past repair when several of these are true together. It runs on a platform or framework that is abandoned and can’t meet a security, app store or compliance requirement. The core data model is wrong for the business, so every new feature has to fight it. Nobody left understands why the system works the way it does, and the original team can’t be reached. Recovery would take longer than the company’s runway. Or the product has already lost the customers or the market window it was built for.

Even then, “too late” usually applies to the code or the plan, not to the business. Most projects past repair still have parts worth keeping.

What you can still do

The gradual replacement option is what Martin Fowler calls the strangler fig pattern, and it is almost always safer than a big rewrite. Joel Spolsky’s argument against rewrites used Netscape as the warning: its rewrite left roughly three years between major releases while competitors moved on. Both assume there is a working system to protect. If there isn’t, a rewrite of a small product can be the right call, as long as someone names exactly what is being thrown away and why.

A ten minute check you can run this week

Answer these honestly, ideally without asking the vendor first. Give yourself one point for every yes.

Zero or one means keep watching and check again next month. Two or three means get an independent review now, while the fixes are still cheap. Four or more means the project is probably already escalating, and the research above says every month of waiting makes recovery slower and more expensive.

The score is not science. It is a way to make the decision on evidence rather than on how optimistic the last status call felt.

How an AvyaTech audit works

We finish the software projects other teams left behind, and every rescue starts the same way: a fixed fee audit that tells you, in writing, how serious things are.

A senior engineer reviews your code, hosting, deployment setup and open issues, and talks to whoever is still around from the previous team. Within [5 to 10] working days you get a recovery plan that ranks every problem by its effect on users and revenue, recommends fixing or rebuilding each major part, and estimates the effort. If the honest answer is that a part of the product should be stopped, the plan says that too. The audit costs [fixed fee amount], we sign an NDA before seeing anything, and the plan is yours whether or not we do the work afterwards.

If you scored two or more on the check above, that is the point where an audit pays for itself. For the full picture of what a rescue involves, read our software project rescue guide.

Book a fixed fee rescue audit

Frequently asked questions