Our Software Project Is Six Months Late and Over Budget — Is It Rescuable

The answer to whether a delayed, over-budget software project is rescuable depends less on how much has been spent and more on what has been built. Sunk cost is not the right framework for this decision. The right question is whether the path forward — completing or salvaging the project — is clearly scoped and achievable within a budget you're willing to commit to.

That's a different question, and it's harder to answer than it sounds.

What "rescuable" actually means

A project is rescuable if two conditions are true: the work completed to date represents real progress toward a working system, and the remaining scope is now accurately understood. Neither condition is always true after six months of overruns.

The harder question isn't whether you can finish — it's whether what you're finishing is worth finishing. A project that's six months late because the scope grew 60% is a different situation than one that's six months late because the original estimate was simply wrong. Both are rescuable, but the path and the cost are different.

Signs the project can be recovered

The technical foundation is sound. If the architecture and data model are well-designed, much of the slow progress may be in features or integrations that can be descoped or sequenced differently. A solid foundation with incomplete features is a much better position than completed features built on a broken foundation.

The delays have a clear cause. Scope additions, a specific integration problem, a team issue — these are solvable. If nobody can explain clearly and specifically why the project is late, that's more concerning than any single identifiable cause.

There is working software. If there's a version of the system that handles the core workflows — even if it's incomplete — that's a foundation to build from. If there's nothing working after six months, you need to understand why before making any decision about continuing.

The requirements are now stable. Many projects run late because the requirements changed repeatedly. If that's resolved and the remaining scope is defined and agreed on, the remaining work may be straightforwardly deliverable.

Signs it isn't

The vendor can't describe the current state of the codebase. If you ask what's been built and get a vague answer, that's a warning. Six months in, you should be able to see working software and get a coherent description of its architecture.

Completion requires redesigning the foundation. If a critical requirement needs a different data model, a different integration architecture, or a rewrite of the core services, the cost is effectively a restart. This isn't always visible until you do a technical assessment, but it's not uncommon.

The team has turned over significantly. This is common on projects that run long — people leave, and the institutional knowledge about why things were built a certain way leaves with them. A project that has had significant team attrition is harder to recover because the new team has to understand the existing code before they can make progress on it.

What a rescue actually involves

A realistic rescue starts with a technical assessment: what's been built, what it does, what completing it would actually take, and whether the existing architecture can carry the remaining requirements. This should take one to two weeks, not months. It produces a clear picture of the current state and an honest scope estimate for completion.

From there, the decision is whether to continue with the current codebase and team, bring in additional expertise, or accept that the project needs to restart on a more realistic foundation. Each of those paths has a different cost and risk profile, and the decision should be made with accurate information about all three.

When to make the call

If a project is six months late and you don't have clarity on when it will be done, the cost of a two-week technical assessment is small relative to the cost of continuing without accurate information. The assessment won't necessarily save the project, but it will give you what you need to make the right decision — and make it before you've spent another six months.

The organizations that recover successfully from these situations are usually the ones willing to hear an honest assessment of where things stand, even when the answer is not what they were hoping for.