Most ITSM implementations that struggle do not fail at go-live. The system works. The configuration is sound. The vendor delivered what was promised. The failure develops earlier — sometimes months earlier — through a set of stakeholder dynamics that are largely predictable, rarely named explicitly, and almost never addressed until the damage is done.
These patterns repeat across organisations of different sizes, sectors, and maturity levels. The platform changes. The patterns do not. What makes them especially difficult to manage is not that they are complex — it is that they do not announce themselves. By the time they are visible, the leverage to fix them has already passed.
Below are five failure patterns that account for the majority of ITSM adoption problems we see. None of them is a technical issue.
The five patterns
The executive sponsor commits at kickoff. They attend the steering committee. Their name is on the project charter and in the all-staff announcement. Then, three months into a nine-month programme, the project becomes one of fifteen things on their agenda. By month six they are receiving a fortnightly RAG status update and nothing else. Their relationship with the programme's operational reality — the cultural tensions, the workflow concerns, the pockets of quiet resistance — is thin.
When adoption resistance surfaces at go-live, they are not equipped to provide credible, visible support. They do not know enough about what actually happened in the preceding months to speak to it with authority. And the organisation can tell.
The operations leader, the HR director, the finance controller — whoever runs the business unit most affected by the change — was briefed on the project rather than involved in shaping it. They were shown a solution after the key decisions had been made. They did not raise a formal objection. They are not, in any observable sense, opposed. But they were given a done decision rather than a problem to help solve.
Their teams read their body language. In one-to-ones, in team meetings, in the moments before training sessions begin, the tone they set about the change shapes how their people approach it. A department head who is genuinely invested creates an environment where adoption is expected. One who is not — however professionally they conduct themselves — creates an environment where it is optional.
This is the one that formal governance does not surface. There is an experienced practitioner — not necessarily senior, possibly not visible to the project team at all — whose opinion carries genuine weight in their team. They understand the old system well. They were not meaningfully involved in the design of the new one. They have reservations about the approach, and they express those reservations to their colleagues in the way that experienced practitioners do: quietly, credibly, and persistently.
Their scepticism spreads laterally. It does not take the form of formal complaints or escalations. It takes the form of colleagues who come to training already guarded, users who raise workarounds in the first week as if they had been pre-agreed, and adoption metrics that plateau at sixty percent without a clear explanation. The resistance was there from the start. The project just never saw it.
The platform has been configured for months. Decisions have been made about process design, form structure, ticket categories, and approval workflows. Then, in the two weeks before go-live, several hundred people are told their working environment is about to change and given training sessions to prepare them for it. The sessions cover what the system does. They do not cover why processes were designed this way, what the system replaces, or what to do when something unexpected happens on Day 1.
The result is not that users cannot use the system — most can navigate it adequately. The result is that they lack the context to understand it, the confidence to trust it, and the institutional knowledge to work within it consistently. Workarounds emerge not from resistance but from uncertainty. Once workarounds are in place, they are very difficult to remove.
Line managers are a layer that implementation programmes consistently underestimate. They were in the all-staff briefing. They received the same communications as everyone else. But when a member of their team asks — in a one-to-one, on the way to a meeting, in the chat channel — "why are we doing this?", they either wing an answer, deflect to the project team, or give an inaccurate explanation that quietly undermines everything the communications plan has been trying to establish.
This is not a competence problem. It is a preparation problem. Line managers who were not given specific language, specific talking points, and a clear escalation path for questions they cannot answer are placed in an impossible position. And unlike the influential sceptic, whose impact is at least visible in retrospect, the invisible middle creates adoption gaps that are genuinely difficult to diagnose after the fact.
Why these patterns are hard to see coming
None of the five patterns announces itself. The fading sponsor still shows up at governance. The consulted-after-the-fact department head does not raise a formal objection. The influential sceptic does not send a complaint to the project team. The line manager does not flag that they felt underprepared. The signals are there, but they require active monitoring of the right things — team dynamics, individual stakeholder engagement quality, communication feedback loops — rather than passive tracking of milestones and RAG status.
The cost of managing these patterns early is low. The cost of recovering from them after go-live is reliably higher — and the window to intervene shrinks every week the project progresses.
This is also why post-implementation reviews so often conclude that the warning signs were visible in retrospect. They were. But the project was optimising for delivery milestones, not for the early indicators of stakeholder drift — and the two rarely appear on the same dashboard.
What changes when you name them early
Every one of these patterns is addressable, but only if identified before the point where the options for intervention have narrowed. The earlier the identification, the lower the cost and the broader the range of responses available.
Sponsor rhythm
A structured engagement cadence — not governance reporting, but specific moments that keep the sponsor genuinely informed of programme dynamics and give them concrete ways to demonstrate visible investment.
Early dept head involvement
Involving business unit leaders at the point where their input can still shape process design — not presenting them with completed decisions. Leaders who helped build the solution support the solution.
Influence mapping
A stakeholder map that captures informal influence networks alongside formal authority — identifying the practitioners whose opinions shape team behaviour and engaging them early enough to convert scepticism into advocacy.
Manager preparation
Specific briefing materials for line managers — talking points, FAQs, escalation paths — so they can handle their team's questions with confidence rather than winging it or redirecting every conversation to the project team.
The underlying principle is consistent across all five patterns: people support what they have been genuinely involved in, adequately prepared for, and honestly informed about. None of this is complicated. It is simply earlier, more deliberate, and more sustained than most implementation programmes treat it.
Allied ESM Change & Adoption
Allied ESM's Change & Adoption practice addresses the people side of every Halo ITSM implementation — from stakeholder mapping and influence analysis at the start, through to champion networks, manager briefings, and post-go-live hypercare. If any of these patterns feel familiar from a previous implementation, or if you want to ensure they do not apply to the next one, our readiness checklist is a useful starting point.