Technical debt in agency systems: how to name it and fund it

Reference article · 5 min read

Technical debt is a real obligation, but the phrase travels badly outside the IT department. To a finance director it can sound like jargon for work the technology staff would prefer to do. The first task is not persuasion. It is naming: describing specific conditions in specific systems, in terms that connect to service delivery, staff time, and financial exposure the agency already tracks.

Government already has a working vocabulary for this. Agencies fund deferred maintenance on roofs, pumps, and bridges, and publish plans saying what happens if a replacement slips another year. Technical debt is the same idea applied to software, configuration, and integrations. The work is to build an inventory that survives questions, rank it by risk rather than age, and carry a recurring remediation line in the operating budget.

The forms agency technical debt usually takes

Debt is easier to fund when it is specific. Most of what agencies carry falls into a few conditions, each documentable system by system.

• Unsupported versions. The operating system, database, framework, or application is past its published support date, so fixes and security patches no longer arrive. Record the version, that date, and what a return to support requires.
• Undocumented customizations. Code or configuration written for the agency that no one has described in writing. The risk is less the customization than that nobody can predict what an upgrade will break, so upgrades stop happening.
• Brittle integrations. Point to point connections that move data on a schedule through file drops, database links, or scripts on one server under one account. They fail quietly, and the failure surfaces days later in a report someone no longer trusts.
• Manual workarounds. Steps staff perform daily because the system cannot: rekeying between two systems, reconciling lists, exporting to a spreadsheet to produce a required report. Each is a recurring labor cost that never appears in a technology budget.
• Single points of knowledge. One employee understands the billing calculation, the interface schedule, or why a field is used differently than its label suggests. When that person retires, the debt stops being theoretical.

Translating debt into budget language

A finance director weighs obligations against revenue, not architecture. Translate each entry into a consequence the agency already recognizes.

• Service continuity. Name the public service that degrades, not the component that fails: permits not issued, payments not posted, records not written.
• Staff time. Have staff log a workaround for a week or two and report what you measured. Measured hours hold up under follow up questions; estimates do not.
• Unplanned spending. Debt that fails on its own schedule gets paid for through emergency procurement, sole source justifications, overtime, and rates set under pressure. Planned replacement spans budget cycles once procurement, migration, and training are counted, so the decision has to come before the failure.
• Compliance and insurance exposure. Unsupported components often conflict with the agency's own security policy and with conditions attached to data received from state or federal partners. Cyber liability carriers also ask about supported software. Requirements vary by program and change, so confirm current language with the granting agency, the carrier, or counsel.

Build the register before you rank anything

Keep the inventory short enough to stay current. One page per system, refreshed on a schedule, beats a detailed document written once.

1. System name and the service it delivers.
2. Vendor, version, and published support status.
3. Customizations, and whether documentation for them exists.
4. Integrations in and out, and how each one moves data.
5. Manual workarounds staff perform, and how often.
6. Who can operate and repair it, and where only one person can.
7. Contract end date and what renewal or replacement would require.

Rank by risk, not by age

Age is easy to measure and a poor guide. A long serving system that is supported, documented, and understood by several staff is safer than a recent one carrying a customization nobody can explain. Score each entry on two questions: how likely is it to fail or become unworkable within the next budget cycle, and what happens to the public if it does. Items whose failure interrupts a statutory duty or a public safety function belong at the top regardless of the technology's age. Saying plainly that other items are old but stable makes the list more credible.

Fund it as a line, not as a rescue

Carry a plainly named recurring line in the operating budget, such as system remediation and deferred technology maintenance. This work is usually too small for a capital project and too continuous for a one time request. Report against it as facilities reports against maintenance: what was retired, what remains, what moved up the ranking. Visible retirements build credibility for larger requests.

Prevent new debt in the contract

Ask these before award, and convert the answers into acceptance criteria and payment milestones rather than promises.

• Upgrade cadence. How often releases are published, how long each version is supported, and what the agency must do to stay current.
• Configuration over customization. Which requirements are met by configuration, which by supported extension points, and which by custom code, and who maintains that code across upgrades.
• Documentation as a deliverable. Configuration, interfaces, and custom logic documented and formally accepted, not available on request.
• Data access and exit. Full export of agency data in documented formats, on demand, during the term and at termination.
• Environments and testing. A non production environment, advance notice of releases, and time to test before upgrades reach production.
• Knowledge transfer. Named staff trained, sessions recorded, and runbooks delivered so operating knowledge does not rest with one person.

HQT works with state and local agencies on system modernization and technology advisory work, including assessment of existing systems and the planning that follows.

Frequently asked questions