Every blown modernization budget gets defended the same way at the end: "we delivered." Nobody stands up at the closeout meeting and says the project failed. What they say is that the team shipped a system, it's in production, and the remaining items have been "deferred to phase two." That sentence is doing an enormous amount of work, and it is worth learning to hear it as the alarm it is.
The descope spiral is not a single decision. It is a ratchet. Each turn looks reasonable in isolation — a feature pushed to a later release, an integration marked "out of scope for MVP," a data-migration edge case reclassified as "manual cleanup." No single turn is a scandal. The scandal is the sum: by the time the system reaches production, "done" has been redefined so many times that it now means something close to "the parts that were achievable on the money already spent," rather than "the system does what the business needed it to do."
How the ratchet turns
The mechanism is structural, not a matter of bad faith on any one person's part. A fixed deadline and a fixed budget meet a workload that turns out to be bigger than anyone scoped, because legacy systems always are — the true behavior of a forty-year-old COBOL estate is discovered by conversion, not by requirements gathering. Something has to give, and schedule and budget are the two variables everyone agreed not to move. That leaves scope as the only lever left, and it gets pulled quietly, function by function, in status meetings where the framing is always "let's park this and revisit."
The parking lot rarely gets revisited. Once a capability is descoped, the team that would build it is reassigned, the budget line is closed, and the political cost of reopening it later — after the project has already been declared a success — is higher than the cost of quietly letting it die. The org chart moves on. The gap in functionality becomes somebody else's problem: an ops team building spreadsheets around what the new system can't do, a call center absorbing manual workarounds, a compliance function discovering months later that a reporting requirement it assumed was covered was one of the things parked in year two.
Renaming failure as success
The tell is in the language. Watch for milestones that get redefined mid-project rather than missed. "Go-live" quietly comes to mean "the core ledger functions are live, with reconciliation running in parallel indefinitely" rather than "the legacy system is decommissioned." "Feature parity" comes to mean "parity with the subset of behavior we had time to test," with an asterisk that never gets published outside the delivery team. A program that was chartered to retire a mainframe ends with the mainframe still running, now as a fallback nobody officially admits is load-bearing.
None of this shows up as a single red flag you can point a steering committee at, which is exactly why it works. Each redefinition is defensible in the room where it happens. It only reads as a pattern in hindsight, when someone lines up the original charter next to what actually shipped — and by then the program has already been marked closed and successful in whatever tracking system counts these things.
This is not a hypothetical. Government audit offices document the pattern repeatedly because government programs are one of the few places the paper trail survives contact with a public-records request. The FBI's Sentinel case-management program is a well-documented instance: the Department of Justice's Office of the Inspector General tracked it across multiple reports as the delivery approach and scope were repeatedly restructured over the program's life, with functionality and delivery models revised well past the system's original targets before it was declared operational. The public record there is the OIG reports themselves, not an accusation from a competitor — that is exactly the kind of documentation that makes a pattern namable instead of anonymized.
What stops the ratchet
The only lever that reliably resists a descope spiral is a definition of "done" that was fixed before the project started and cannot be renegotiated by the people being measured against it. That means an explicit, itemized parity target — this list of behaviors, against this reference data, verified this way — agreed to by the buyer before a contract is signed, not discovered as an artifact of what got built. If "done" is defined after the fact by whoever is under pressure to declare victory, it will always shrink to fit whatever shipped.
It also means treating "deferred to phase two" as a decision that requires the same sign-off as the original scope, not a status-meeting shrug. If a capability is important enough to be in the original charter, removing it should cost someone something — a documented exception, a customer-facing risk acknowledgment, a number attached to what the gap actually means in production. Most descope spirals survive specifically because removing scope is administratively free and keeping it is expensive. Flip that cost structure and the ratchet stops turning on its own.
The honest version of a modernization program says, before the meter starts, exactly what "the new system matches the old one" will mean and how it will be checked — deterministically, against real data, not against a demo. Everything that gets called done afterward either meets that bar or it doesn't. There is no room in between for "done" to mean something smaller than what was promised.