Obligation Retirement

A replacement programme's scope is the list of things the legacy system is obliged to keep doing. Every report, every outbound file, every integration, every identifier guarantee is on that list, and each one must be reproduced before the original can be retired.

Obligation retirement attacks the list rather than the plan. Each entry is taken to its named consumer and one of three things is agreed: it is still needed and will be reproduced, it is needed in a different form the new system can produce more cheaply, or it is not needed and will stop.

It is a distinct practice rather than ordinary scope management because the obligation has no owner inside the programme. It has a consumer elsewhere in the organisation who has never been asked whether they still use it. Nobody retires an obligation by accident.

Why it matters

Scope is the dominant cost driver of a replacement, and reducing programme scope while keeping every obligation does not reduce work - it moves the work into a coexistence that keeps the legacy system alive. That is the difference between the two moves, and it is usually invisible in a steering report because both look like "reduced scope".

The yields are consistently underestimated. On a long-lived estate a meaningful share of reports and extracts have no current consumer: a recipient who left, a regulator that changed submission channel, a withdrawn product, a dashboard replaced by another. Rationalisation exercises routinely find a third or more of reports with no reader in the last quarter, and each one removed is scope deleted rather than deferred.

The second effect is on decommissioning. A system cannot be switched off while any obligation points at it. One surviving annual extract keeps an entire platform, its licences and its specialist staff funded for another year - which is why the retirement conversation belongs at the start of a programme, not at the end.

Implementation patterns

• Start from a behaviour inventory, not from a wish list. Scheduled jobs, outbound artefacts, database grants and query logs enumerate the obligations, including the annual ones.
• Attach a consumer and a last-use date to every entry. Access logs answer this for reports and APIs; for files, the destination system's own ingestion logs do.
• Use a time-boxed switch-off trial rather than a survey. Asking "do you still need this" produces yes. Announcing "this stops on 14 March unless someone objects", then stopping it, produces the truth - and is reversible for the retention period.
• Keep the data, retire the delivery. Most objections are about losing history, not about the monthly file. An archived, queryable dataset satisfies them at a fraction of the cost.
• Get retirement authority named before the programme starts. If nobody can say yes to stopping a report, every obligation survives by default and the programme has lost its cheapest lever.
• Count and publish retirements as a programme metric alongside delivery, so the work is visible.

Industry example

Public tax systems show the cost of the opposite choice. The US Government Accountability Office's reporting on the IRS CADE 2 programme, begun in 2009 to replace a 60-year-old Individual Master File, describes cost, schedule and scope goals revised seven times between 2016 and 2019, a key milestone slipping nine years, and the intended scope reduced to core components only - while the legacy system continued to carry its obligations through every annual filing season, with full retirement planned for 2030 as reported in June 2021. The obligations were statutory and genuinely could not be retired, which is exactly why the scope reduction produced a coexistence rather than a retirement.

Failure scenarios

• The survey that saves nothing. Everyone asked says they still need their report, because answering yes is free and answering no feels risky.
• Retirement without archive. The feed stops, the system is switched off, and three weeks later an annual regulatory extract fails because it read the database directly.
• The one surviving extract. 94 of 95 obligations are retired or migrated; the last one keeps the platform, its support contract and its two specialists funded for a further year.
• Silent re-creation. A retired report reappears as a spreadsheet built from a direct database query, so the obligation survives in an unmanaged form with no owner.
• Retiring the wrong thing. An output with no human reader turns out to feed an automated control, and its absence is discovered by an auditor rather than by a user.

Trade-offs

The real price is organisational: somebody must take a report away from a stakeholder who may complain. The practice fails wherever that authority is not granted, however good the inventory is.

When not to use it

Do not attempt obligation retirement where the obligation is statutory or contractual. A regulatory return, a contractual data feed to a partner or an audit trail with a retention period is not negotiable, and proposing it damages the credibility needed for the negotiable 60%.

Do not use it as a substitute for building the replacement. A programme that retires 40 obligations and delivers nothing has reduced cost and produced no capability.

And skip it entirely for a rehost, where the application and its outputs are unchanged by construction: the obligations travel with the workload and there is nothing to negotiate.

Interview question

Q: Your replacement programme has 95 obligations in scope and is 40% over budget. You are told to reduce scope. What do you do differently from simply deferring features, and how do you get it agreed?

What a strong answer covers: the distinction between reducing programme scope and retiring an obligation, and why only the second shortens coexistence · building the obligation list from logs rather than from documentation · last-use evidence per obligation and a time-boxed switch-off trial rather than a survey · keeping the data while retiring the delivery, which answers most objections · statutory and contractual obligations excluded up front · naming the person with retirement authority before starting · and the honest limit: this reduces what must be rebuilt, it does not deliver anything, so it runs alongside delivery rather than instead of it.

Quick check

Quiz: Why does retiring an obligation reduce cost in a way that deferring programme scope does not? Deferring relocates the work into a coexistence that keeps the legacy system, its licences and its specialists funded; retiring removes the work permanently and is a precondition for switching the old system off.

Flashcard: Why does a survey asking "do you still need this report?" fail, and what works instead? - Answering yes is free and answering no feels risky, so everything survives; announce a stop date, stop it, and keep the data archived and queryable so the change is reversible for the retention period.