advanced 3 min answer

The US Internal Revenue Service began developing CADE 2 in 2009 to replace the Individual Master File, its authoritative record of individual taxpayer accounts, which the Government Accountability Office described as 60 years old and programmed in assembly language. GAO reported that a key milestone slipped nine years from 2014 to 2023, that cost, schedule and scope goals were revised seven times between 2016 and 2019, that development cost is roughly four times the original plan, that the programme now expects to replace only core components, and that in June 2021 the IRS planned full retirement of the master file by 2030. What produced that pattern, and what should a private-sector programme take from it?

gaoirscade 2mainframeprogramme riskcase study
Show the full answer Hide the answer

The situation they were in

The Individual Master File is not a system that can be paused. It is the record of account for every individual taxpayer, it must process a filing season every year on a statutory timetable, and its output feeds refunds and enforcement. The replacement had to be built while the original ran, kept exactly consistent with it, and never allowed to delay a filing season. GAO's 2016 work also found the IRS using assembly language for the system and without time frames for its replacement, which is the assessment position almost every large legacy estate starts from.

What the numbers actually say

  • Nine years of slip on one milestone is not nine years of underestimation. It is a series of annual decisions to protect the filing season by deferring the transition, each individually correct.
  • Seven revisions to cost, schedule and scope in four years describes a programme re-planning roughly every seven months. At that rate the plan is a forecast, not a commitment, and the board conversation shifts from delivery to credibility.
  • Scope reduced to core components is the most instructive number. Faced with cost growth, the programme cut what it would replace rather than extend the date again - which means the end state is now a coexistence, not a retirement.
  • 2030 as the full-retirement date, set in 2021 for a programme started in 2009, makes the total intended duration about 21 years. No sponsor, architect or engineer is the same person at both ends.

Why the scope shrank

Because the only lever a programme has when it cannot move the date and cannot move the money is what it delivers. Scope is the compressible dimension, and it compresses towards the part that is easiest to replace rather than the part that most needs replacing. The functions left behind are the ones most entangled with the original, which is why they were left - and they are therefore the ones that keep the old system alive.

What it cost them

Twenty-one years of running both. Every year of coexistence carries the legacy run cost, the duplicate change (a statutory change must land in both), and the staffing of skills the market stopped producing. The business case that funded 2009 cannot have included that, because nobody plans a 21-year coexistence.

Where copying this would be a mistake

Do not read this as "large modernisations fail". Read the constraint: the IRS could not reduce the scope of the legacy system's obligations while it rebuilt them. A commercial organisation usually can, and that is the lever the case study points at.

Three transfers to a private programme:

  1. Fund the legacy run cost as part of the programme, not as business-as-usual. Otherwise each deferral looks free to the decision maker who makes it.
  2. Make coexistence length an explicit, defended number with a cost per month attached. A programme that cannot state its coexistence cost per month will extend it by default.
  3. Cut the obligations before cutting the scope. Retiring a report, a channel or a product variant permanently reduces what must be rebuilt. Reducing programme scope while keeping every obligation just relocates the work into a coexistence nobody is funding.

Common weak answers

  • "Public-sector programmes are just badly run." The pattern reproduces in banks, insurers and telcos with the same constraint: a legacy system whose obligations cannot be reduced while it is being replaced.
  • "They should have rewritten it in one go." For a system that must process a filing season on a statutory date, a single cutover is the one option with no rollback.
  • "Agile delivery would have fixed it." Iteration helps when scope is divisible. The binding constraint here was an undividable annual obligation, which is a scope problem, not a method one.