IT Operations & Service Desk

Operations and maintenance pays for the service desk, patching, monitoring, licenses, and the staff who keep systems available day to day, none of which is optional while the system is in service.

It also gets less scrutiny than modernization, because sustainment is usually carried forward from the previous year rather than planned against milestones and reported against them.

Support costs climb as a system ages. Once a vendor drops support the patches stop, and agencies pay specialists to cover components nobody else maintains, which is the position four of the eleven systems GAO ranks most critical are already in.

Modernization is the long-term answer and it is slow to pay back. The Technology Modernization Fund invested about $1.03 billion across 68 projects between 2018 and 2025, of which eleven had returned about $13.5 million, and 98.3 percent of the projected savings are not expected until fiscal 2027 or later.

The systems being replaced have to keep running throughout that period, and agencies cannot hire quickly enough to staff both efforts, so the people answering tickets are frequently the same people assigned to the modernization.

The work that matters at a service desk is diagnosis. Someone calls because something is broken and they cannot do their job, and what they need is a person who can work out why. Diagnosis takes time and skill, and good instrumentation together with a knowledge base that reflects how the system works today does more for resolution times than adding another support tier.

Most of the queue is not diagnosis. A large share of ticket volume is the same work repeated: password resets, access requests, provisioning, and a small number of recurring application faults, all of which can be automated or moved to self-service to clear the queue for the calls that need a person.

At OCH we run operations on a cycle rather than as a standing watch. Each period closes with a review of what came in, what took longest, and what recurred, and opens with a plan for what we intend to remove before the next one.

We measure before changing anything, because ticket categories, resolution times, and repeat rates show where the cost actually sits and it is rarely where people expect.

The review produces a backlog of its own: automation to build, knowledge articles to write, configuration to correct at the source. We prioritize that backlog against the ticket data rather than against whoever asked most recently.

We write up difficult tickets when they close, covering what the symptom looked like and what it turned out to be, and those write-ups feed both the knowledge base and cross-training so diagnosis does not depend on who happens to be on shift.

Where we also hold the application, we push fixes back into the code instead of letting workarounds become permanent, and the recurring tickets that justified the fix are the evidence for it.