When to Kill a Failing Project

The continue-or-stop decision has two inputs: the cost to complete from today, and the value of the completed system. Money already spent is not one of them, and treating it as one is the primary reason organizations continue projects they should stop.

The stated reasoning — too much has been invested to stop now — describes a sentiment rather than an analysis. Prior expenditure is unrecoverable under either decision, which makes it irrelevant to comparing them.

Conditions that indicate stopping

Four conditions, each observable without a deep technical review.

Requirements have fundamentally changed more than twice. Not refinement, but changes to what the system is for. This indicates the problem has not been defined, which is a planning failure. Additional engineering does not resolve it, and every further requirement change invalidates work already completed.

The codebase is unmaintainable inside a year. A system built recently that the team already avoids changing has a foundation that will not support the remaining scope. The remaining work is subject to the same conditions that produced the current state.

The team has turned over twice. Institutional knowledge is gone. Any continuation is effectively a restart, performed by people reading unfamiliar code rather than people writing new code, which is the more expensive of the two.

The business case has expired. The market condition, regulatory deadline, or contract that justified the project no longer exists. A technically recoverable project with no remaining business justification should still stop, and stopping for that reason is a correct outcome rather than a failure.

Conditions that support continuing

The strongest case for continuing is that the technical foundation is sound and execution was the constraint.

The distinction that determines this: a project at 70% complete with working core functionality and a defined remaining scope is a different asset from one at 70% complete where the remaining 30% depends on architectural questions that have not been answered. The first has a completion cost that can be estimated. The second does not, because the unresolved architecture is what would produce the estimate.

Supporting indicators:

• Core domain logic works and produces correct results against real data
• The remaining scope is enumerable and each item is estimable
• Failures trace to schedule, staffing, or requirements management rather than to structural decisions
• The data model holds up against the full requirement set, not just implemented features

Selective salvage

Most assessments treat this as binary and miss the option with the best return: keep the components representing genuine progress and replace the rest.

Frequently worth preserving:

• The database schema, where it models the business correctly
• Domain logic and calculation engines validated against real cases
• Integration adapters where the negotiation with the external system has been done
• Test suites and the production data sets used to build them

Frequently worth replacing:

• The presentation layer
• Infrastructure, deployment, and configuration
• Framework choices that constrained everything downstream

This is faster than a full rebuild and produces a better result than continuing to work around a compromised foundation. It requires a component-level assessment, which is why it is missed by reviews that evaluate the project as a single unit.

Who makes the call

The assessment should be produced by someone with no involvement in the work and no financial interest in either outcome.

People closest to a struggling project have the least ability to distinguish problems that additional effort will resolve from problems that are structural, and the constraint is informational rather than a matter of character. They have been solving one problem at a time for months, and each individual problem was solvable.

The assessment should produce specific deliverables: an inventory of what works against real data, the estimated cost to complete the remaining scope on the current foundation, a component-level salvage recommendation, and a comparison of that path against a fresh start.

Committing to the decision

Both outcomes require full commitment, and the failure mode is the third option that nobody selected.

Continuation with reduced funding and reduced attention extends the expenditure without changing the result. That state — a project consuming budget while delivering nothing, because no one will make the call — costs more than either decision made cleanly, and it is the most common outcome of an assessment nobody acts on.