What a Technology Investment Should Leave Behind

A practical approach to judging technology spending by the operating improvements and enduring capabilities it creates.

When I evaluate a technology investment, I want to know what the organization will be able to do after implementation and what it will take to sustain that capability. The answer should guide the funding decision and remain useful after deployment.

My responsibility for technology budgets began as a legislative correspondent and systems administrator. I developed proposals with senior staff, presented them to the Member, and carried that responsibility into leadership at the House Committee on Rules and the House Committee on the Judiciary. Planning, defending, and executing those decisions required a clear purpose and a credible account of delivery and continuing support.

I carry that perspective into modernization and AI adoption. A business case should explain how the investment will improve a service, make information more dependable, or provide capacity for work the organization needs to do.

Define the operating change

Start with the work that needs to improve. If staff spend hours reconciling conflicting records, establish where the conflicts arise and what resolving them requires. If customers struggle to complete a request, examine the whole process, including steps handled outside the application. A faster screen will have limited effect if the request still waits in an unmanaged queue.

At the House Committee on Judiciary, I inherited a hearing-room projection system that needed the room to be almost completely dark to be useful. That was a poor fit for the proceedings it was meant to support. I evaluated alternatives and led a modernization that included a video wall and larger side displays, along with improvements to the room’s audio and timing systems.

The requirement was straightforward: people needed to use supporting material under normal hearing conditions. The members, witnesses, and audience needed to be able to view those materials. That requirement shaped the equipment decision. It also meant considering the room and its connected systems together. The value of the project depended on whether the resulting service worked during proceedings, beyond how impressive the equipment looked in a demonstration.

Describe an observable outcome, such as shorter completion time, fewer returned requests, better access to records, or a new service. Assign an owner and establish a baseline before the change.

Compare improving the existing workflow, replacing a component, purchasing a service, and building a platform. Include the consequences of maintaining the current approach. Each option should identify the problem it solves and the obligations it creates.

Distinguish capacity from cash savings

Consider a hypothetical team processing 1,000 records monthly at 12 minutes each: 200 hours of staff effort. A proposed tool cuts preparation to four minutes, with another three minutes for review and correction. The new workflow takes 116.7 hours, releasing 83.3 hours before additional support and administration.

The released hours could reduce a backlog or improve service. If payroll and contractor spending remain unchanged, the result is additional capacity. A cash-savings claim requires a corresponding reduction or avoidance of expenditure.

At an illustrative labor value of $60 an hour, 83.3 hours represent approximately $5,000 in gross monthly capacity value. Subscriptions, implementation, training, support, and quality costs still need to be assessed. The estimate also depends on workload and whether the released time can be used productively.

Some investments deserve funding because they improve service or reduce operational exposure without cutting expenditure. Those benefits need their own evidence and measures.

Fund the complete service

The funding decision creates obligations beyond installation. Someone must maintain the information, support users, manage changes, and respond when the service fails. A realistic estimate includes integration and migration work, the transition period, and the continuing cost of keeping the capability useful.

For AI, that means considering review effort, monitoring, exceptions, and the work required when models or source material change. For a conventional platform, it may mean data cleanup, process redesign, or maintaining an older system until the transition is complete. These costs belong in the decision while options are still open.

The Digital Services Playbook connects user needs and the complete service experience with budgeting, accountable leadership, and performance measurement. (Digital Services Playbook) I see a practical management obligation in that connection: the person approving the investment should understand how the organization will operate the service after the project team moves on.

Use evidence to decide what happens next

A limited implementation can test the assumptions that matter most before the organization makes a larger commitment. Define what the test needs to establish, including quality, staff effort, adoption, and support needs. Give the pilot an owner and a decision point so that it produces evidence for a choice.

Review that evidence against the original purpose. A tool may perform well technically while requiring more operating effort than expected. Another may justify expansion because it improves a service that people depend on. Changing scope, renegotiating, or stopping should remain available when the evidence supports those decisions.

Examine what the organization will retain as platforms evolve. Usable data, dependable systems of record, and staff knowledge can support later changes. Establish what can be exported, how a transition would work, and what a successor team must understand.

Before approving an investment, ask what capability is being purchased, how its value will be observed, and who will sustain it. Return to that account after deployment to assess whether the improvement and continuing cost remain justified.