Why enterprise software gets replaced before it is finished

There is a familiar shape to large enterprise programmes. Two years in, with the platform perhaps seventy percent delivered, someone senior asks whether it still makes sense. The requirements were written for an operating model that has since changed twice. The vendor landscape has moved. The sponsor has moved. Nobody wants to say it, but the honest answer is that finishing would deliver a system designed for a company that no longer exists.

This is usually diagnosed as poor execution. More often it is a design assumption — that a three-year build can be specified against a snapshot of the business taken at the start.

Requirements have a half-life

Every requirement is a statement about how the business works, and businesses change. Regulation arrives. Acquisitions land. A competitor reframes what customers expect. The half-life of a detailed enterprise requirement is shorter than most programme timelines, which means a long build is guaranteed to deliver a proportion of its scope already obsolete on the day it lands.

The failure is not that requirements changed. It is that the delivery model treated change as an exception to be governed rather than a condition to be designed for.

What changes the outcome

• Deliver value in increments the business can actually use, not increments only the programme can measure. A milestone nobody outside the programme can feel is not progress; it is expenditure.
• Sequence by decision reversibility. Make the choices that are hardest to unwind last, once you have learned the most.
• Keep the architecture composable, so a change in one domain does not require renegotiating the whole design.
• Re-underwrite the business case annually, honestly, with the option of stopping genuinely on the table.
• Give the programme a product owner with authority rather than a steering committee with opinions.

The uncomfortable discipline

The hardest practice here is the willingness to stop. Large programmes develop a gravity of their own: the sunk cost is visible, the careers attached to it are real, and the cost of continuing is spread across future budgets where it is easier to ignore.

Organisations that avoid the trap tend to share one habit. They fund programmes in tranches against demonstrated value rather than approving them once against a plan. It makes the annual conversation harder and the three-year outcome dramatically better — because a programme that must re-earn its funding stays attached to a business that keeps moving.