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

A project is rescuable when two conditions hold: the completed work represents genuine progress toward a working system, and the remaining scope is now accurately understood. Amount spent is not an input to that determination.

Neither condition is automatically true after six months of overruns, and the second one fails more often than the first. A team that does not know what remains cannot be given a budget to finish, regardless of how sound the existing code is.

Distinguish the two failure causes

A project six months late because scope grew 60% is a different situation from one six months late because the original estimate was wrong. Both can be recovered; the path and the cost differ.

• Scope growth produces a project that has been delivering steadily against a moving target. The remedy is fixing the target. Velocity data from the project is reliable and usable for re-estimating.
• Estimate error produces a project delivering below the rate the plan assumed, against unchanged scope. The remedy requires establishing the actual rate and rebuilding the schedule on it. The original estimate is unusable.

Distinguishing them requires comparing current scope against the scope at kickoff, not against the last checkpoint.

Indicators the project can be recovered

The technical foundation holds. A sound architecture and data model with incomplete features is a substantially better position than completed features on a foundation that will not carry the remaining requirements. Slow progress on features is recoverable through descoping and resequencing. A wrong data model is not.

The delay has a specific, nameable cause. Scope additions, a particular integration, a staffing gap. Each is addressable. If nobody can state specifically why the project is late, that is more concerning than any single identifiable cause, because it means the mechanism is still operating and unmeasured.

Working software exists. A version handling the core workflows, even incompletely, is a foundation. Nothing running after six months requires an explanation before any decision about continuing is made.

Requirements are now stable. Many projects run late because requirements changed repeatedly. Where that has resolved and the remaining scope is defined and agreed, the remaining work may be straightforwardly deliverable at a rate the project has already demonstrated.

Indicators it is not

The vendor cannot describe the current state of the codebase. Six months in, working software should be demonstrable and the architecture describable in specific terms. A vague answer to what has been built is the strongest single negative signal available.

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 approximates a restart. This is frequently not visible without a technical assessment, and it is not uncommon.

The team has turned over substantially. Common on long-running projects, and it compounds the problem. Institutional knowledge about why decisions were made leaves with the people who made them, and the replacement team spends its first months reading code rather than writing it.

What the assessment produces

A technical assessment precedes any decision, and it takes one to two weeks rather than months.

Required outputs:

• What has been built, verified by running it against real data rather than by reviewing tickets
• What each partially complete item requires to finish, itemized
• Whether the existing architecture can carry the remaining requirements
• A completion estimate built on observed velocity, not on the original plan
• A component-level recommendation on what to keep and what to replace

From there the decision is among three paths: continue with the current codebase and team, add expertise to the current codebase, or restart on a foundation that reflects what is now known. Each carries a different cost and risk profile, and the choice should be made with accurate figures for all three.

Timing

At six months late with no clarity on the completion date, a two-week assessment costs little relative to continuing without accurate information.

The assessment does not by itself save the project. It produces the information required to make the decision, and it produces it before another six months are spent. Organizations that recover from this position are consistently the ones willing to act on an honest assessment of where things stand, including when the assessment says to stop.