Mike Phillips Tech

The problem isn’t the platforms. It’s everything agencies do before, during, and after they deploy them.

By Mike Phillips

The federal government spends close to $100 billion on information technology every year. A significant portion of that goes toward IT Service Management platforms — the enterprise software systems that agencies use to manage incidents, process service requests, track changes, and maintain the operational infrastructure that everything else runs on. ServiceNow alone has become so deeply embedded in the federal landscape that it’s difficult to name a major agency that isn’t running some version of it.

And yet, across over a decade of working inside those implementations — at the U.S. Department of State, the National Institutes of Health, and other federal environments — I watched the same failures repeat themselves with remarkable consistency. Not because the platforms don’t work. They do. The failures happen because agencies consistently misunderstand what they’re actually buying, what it takes to deploy it successfully, and what has to happen after go-live to make the investment pay off.

The pattern is structural. And until agencies address it structurally, the failures will continue.

The Procurement Problem: Buying the Platform, Not the Outcome

The first failure happens before a single line of configuration is written.

Federal agencies typically aren’t experts on the intricacies of the digital transformation projects they want to implement — which is why they call on industry to propose solutions. But if you’re not qualified to design the solution, you’re likely not able to accurately estimate the level of effort or the total cost of ownership for the platforms you’re seeking.

That gap between what agencies think they’re buying and what they actually need is where most implementations begin to go wrong.

ITSM platforms like ServiceNow are sold as configurable solutions. What that means in practice is that the platform is a framework — a set of capabilities that have to be shaped, configured, and integrated to match the agency’s actual workflows, processes, and technical environment. The base platform, as purchased, does not do what an agency needs it to do. Someone has to make it do that. That someone is almost never the vendor at the price quoted.

At the State Department, we discovered early in the engagement that the contracted implementation scope covered platform infrastructure — not the bureau-specific workflows that made up the agency’s actual service operations. Every bureau operated differently. Every integration with a legacy system required custom development and data migration. Every deviation from out-of-the-box configuration — and there were dozens — required additional scope, additional time, and additional budget.

None of that was hidden. It was the predictable consequence of procurement criteria that evaluated platform licensing cost rather than total deployment cost. The agency bought the platform. It hadn’t bought the outcome.

The fix: Agencies need to treat implementation scoping as a pre-award activity, not a post-award discovery. That means engaging implementation partners during the procurement phase — not just to evaluate their approach, but to produce a detailed, line-item breakdown of the configuration, integration, and customization work required before the contract is signed.

The Process Problem: Deploying Software Into Broken Workflows

The second failure is subtler and more damaging.

ITSM platforms are process enforcement tools. They codify workflows, route requests, track changes, and measure performance against defined service levels. When they work, they work because the underlying processes are sound — clearly defined, consistently followed, and appropriate to the organization’s actual service model.

In most federal agencies, those conditions don’t exist before implementation begins.

The federal government has a large number of agencies, each with its own IT systems and infrastructure. This fragmentation can make it difficult for agencies to coordinate and share resources, leading to duplicated efforts and higher costs. That fragmentation isn’t just a technology problem — it’s a process problem. Agencies frequently have different bureaus, offices, and components operating with inconsistent workflows, informal workarounds, and institutional knowledge that lives in people rather than documentation.

When an ITSM platform gets deployed into that environment, it doesn’t fix the process fragmentation. It inherits it. The platform gets configured to match the broken workflows because those workflows are what stakeholders describe during requirements gathering. The result is an enterprise system that automates dysfunction rather than replacing it.

I watched this happen repeatedly. Incident management processes that should have been standardized across an agency were instead replicated in platform configuration as a half-dozen variations — because each bureau insisted its process was different, and no one had the authority or the will to enforce standardization before go-live.

Six months after deployment, the platform was technically live. Nobody was using it the same way. The efficiency gains that justified the investment hadn’t materialized. The agency had a new platform built on top of the same old process problems.

The fix: ITSM implementation should be preceded by a process standardization effort, not just a requirements gathering exercise. Agencies need to decide — before configuration begins — what their service management processes are actually going to be. That work is organizational, not technical. It requires executive sponsorship, stakeholder alignment, and a willingness to override bureau-level preferences in favor of enterprise consistency. It is also the work that implementation vendors are least equipped and least incentivized to lead, which means agencies have to own it themselves.

The Governance Problem: No One Owns the Platform After Go-Live

The third failure is the one that turns a mediocre implementation into a long-term liability.

Enterprise ITSM platforms don’t run themselves. They require ongoing administration — user provisioning, configuration management, integration maintenance, performance monitoring, upgrade planning, and a continuous cycle of improvement as business needs evolve. In a large federal environment, that administrative load is substantial. A well-deployed ServiceNow instance supporting thousands of users across multiple bureaus requires dedicated platform administrators who understand the system deeply enough to keep it stable, evolve it appropriately, and prevent configuration drift from degrading the investment over time.

Most agencies don’t staff for this. The assumption — usually unstated — is that existing IT operations teams will absorb the platform administration workload. That assumption is wrong, and the consequences unfold slowly enough that the connection between cause and effect is easy to miss.

What actually happens: the implementation team leaves. The agency’s IT staff, already resource-constrained, takes on platform administration as an additional responsibility on top of their existing workload. Government IT teams are often resource-constrained and challenged by their goals — asked to implement and support more without the additional resources they truly need to make progress, while still working to support and maintain existing legacy systems.

Upgrades get delayed. Configuration changes accumulate without proper change control. Integrations break and stay broken longer than they should. The platform’s capabilities stagnate while the vendor’s roadmap advances, creating an expanding gap between what the platform could do and what the agency is actually using it for.

Within two or three years, many agencies find themselves running a degraded version of the platform they deployed — and facing the prospect of a costly re-implementation to close the gap.

The fix: Platform administration capacity needs to be treated as a line item in the implementation business case, not an afterthought. Before procurement, agencies should assess honestly whether they have the internal capacity to administer the platform at scale. If they don’t — and most don’t — the total cost of ownership calculation must include either the ongoing cost of managed services or the cost of hiring dedicated platform administrators. The optimistic assumption that existing staff will figure it out is not a plan.

The Adoption Problem: Assuming Deployment Equals Use

The fourth failure is the one that embarrasses agencies the most, because it’s the most visible.

Go-live is not adoption. A platform that’s technically live but isn’t being used correctly delivers approximately zero return on the investment made to deploy it. And across federal ITSM implementations, low adoption is endemic.

While most organizations use some sort of IT ticketing system, many have still not embraced full IT service management or life-cycle delivery with integrated processes. In practice, this means users route requests through email, informal channels, or legacy systems that should have been retired — in parallel with the new platform — because they’re more comfortable with what they already know.

The reasons are predictable. Training is compressed. Change management is treated as a communications exercise rather than a behavioral change effort. End users aren’t consulted during design, so the configured platform doesn’t match their actual workflows. And when problems arise after go-live — and they always do — the informal channels are faster and more reliable than the new system, which reinforces the avoidance behavior.

I’ve seen agencies spend millions on ServiceNow deployments and fail to achieve consistent incident management adoption across their user base within the first year. The platform worked. The data was there. The workflows were configured. Nobody was using them correctly because nobody had made using them correctly easier than not using them at all.

The fix: Change management needs to be budgeted as a non-negotiable implementation component, not a line item that gets cut when budgets tighten. That means real end-user training — not a two-hour webinar — scheduled close enough to go-live that skills don’t atrophy before they’re needed. It means involving end users in the design process so the configured platform reflects how work actually gets done. And it means having a plan for the first 90 days after go-live, when adoption patterns are set, and course corrections are still relatively cheap.

The Underlying Pattern

These four failures — procurement, process, governance, and adoption — are not independent problems. They are symptoms of a single structural issue: federal agencies consistently treat ITSM implementation as a technology project when it is fundamentally an organizational change effort.

Technology projects have a defined scope, a delivery date, and a completion milestone. Organizational change efforts don’t end at go-live. They require sustained leadership commitment, ongoing investment, and a willingness to hold the organization accountable to new ways of working over months and years.

Agencies need to understand that selecting a government project manager should be done with the same rigor used when selecting the vendor. That applies equally to the organizational change leadership required to make an ITSM implementation succeed. The technical delivery is the easy part. The hard part — aligning processes, building adoption, sustaining governance — is organizational, and it requires organizational ownership at a level most agencies don’t assign until something has already gone wrong.

The agencies that get this right are the ones that treat the platform as a means to an operational outcome, not as the outcome itself. They invest in process design before configuration begins. They staff for administration before go-live. They budget for change management as seriously as they budget for licensing. And they hold someone accountable for adoption metrics, not just deployment milestones.

That’s a different kind of implementation than the federal government typically runs. It’s also the only kind that consistently works.