I’ve watched a lot of money disappear. Not embezzled. Not wasted on lavish offices or pointless retreats. Real money. Spent on systems supposed to transform how people work, only to end up abandoned while everyone goes back to email and spreadsheets.
After 25 years in IT Service Management, I’ve seen enough ITSM implementations fail that I’ve stopped being shocked. I’ve learned something from those failures. They almost never fail because the process is bad or the tool is weak. They fail because organizations treat implementation like construction, when it’s actually more like planting a garden.
The Garden
When you plant a garden, you don’t just buy the best seeds, dig a hole, and expect harvest in three weeks. You prep the soil. You figure out what your garden actually needs. You get people who understand why they’re doing it. And you tend it. Not once, not with a ribbon cutting. Constantly. Watering, weeding, adjusting based on what actually works in your specific patch of land.
ITSM implementations fail because organizations approach them like construction. Hire the contractor. Follow the blueprint. Cut the ribbon. Done. No tending. No accounting for the fact that soil in your organization is different than soil in the case study. No accounting for people deciding they’d rather not bother with the watering.
What Goes Wrong (And Why It Matters)
I worked at a mid-sized financial services firm. We implemented ServiceNow. $800K when you counted everything. The tool was solid. The process design came from consultants who knew ITIL inside out. Training was comprehensive.
Here’s what happened:
First mistake: no soil preparation. The organization had been running on tribal knowledge. People had relationships that did the work, not systems. When we asked them to log every ticket, work through a queue, measure against SLAs, something broke. Not the tool. The culture of how work actually happened. Nobody had asked if people understood why. They didn’t.
Second mistake: tool bloat without adoption. ServiceNow can do almost anything. So we configured it to do everything. Every field. Every workflow variation. Every report the exec team might want someday. The tool got so complex that the people actually using it found it faster to call someone or email than navigate five screens to log a request. Adoption flatlined. Six months in, we were paying maintenance on a system 40% of the organization had given up on.
Third mistake: no feedback loop. Implementation ends on day 90. The PM leaves. Consultants pack up. Nobody asks the people doing the work if the system is helping. We didn’t find out about our adoption problem until quarterly metrics review. By then the damage was done. People had decided.
Quick definitions
ITSM jargon gets thrown around loosely, so here’s what I mean:
- ITSM (IT Service Management): A framework for delivering IT services using structured processes. How you organize IT work so it reliably serves the people it’s supposed to serve.
- ITIL (IT Infrastructure Library): A set of best practices for IT service management. The playbook. Proven, complete, but not a template you copy into your organization.
- Process adoption: Where implementations die. It’s not training people on the tool. It’s convincing them the new way is actually better than the old way. That takes proof, not promises.
- SLA (Service Level Agreement): Your commitment to users about response time. Without one, no accountability. With one you haven’t staffed or communicated? It becomes a resentment factory.
Why this matters to your organization
A failed ITSM implementation doesn’t just burn the budget. It creates distrust. People think: management spent money on this, it failed, so management doesn’t understand how we actually work. Next time you ask them to adopt something—cloud migration, new protocols—they’re skeptical from day one. You’ve lost credibility.
Your IT organization also gets harder to scale. Without a shared process, you can’t pinpoint bottlenecks. You can’t train new people the same way. You can’t measure where the real waste is. You just have 50 people doing 50 versions of the same job.
And the tool costs keep rising while value stays flat. Licenses for people who don’t use them. Support for a system nobody trusts. Customizations that made sense in theory.
What actually works
Successful implementations do a few things differently.
They start with people. Before ServiceNow, before any system, ask: what’s broken about how we work now? Not in theory. In practice. What frustrates people? What creates delays? What information disappears? Design a process that solves those specific problems. The tool follows after, configured to support what you actually need, not what looks good in a deck.
They build adoption into the plan from the start. Find champions early. People who see the value and can convince others. Run the new process alongside the old one longer than feels comfortable. Ask for feedback and actually listen. Make changes. Celebrate wins, even small ones, out loud.
They tend the garden. Implementation doesn’t end on day 90. You need someone—ideally a process owner who understands both the business and the tool—who owns continuous improvement. Every quarter, ask: are people using it? Is it solving the problems we said it would? What’s not working? What do we adjust? Then adjust. Visibly. Fast.
The forward view
ITSM isn’t broken. ServiceNow, Jira Service Management, BMC Helix—solid platforms. The frameworks work when they’re applied thoughtfully. Not installed like software on a machine. Woven into how people actually work.
If you’re planning an implementation, treat it like a garden. Prep the soil. Plant what your organization actually needs. Tend it constantly. The harvest takes longer than the project plan says. But if you do it right, you’ll benefit for years.
The difference between an ITSM implementation that transforms an organization and one that becomes expensive shelf-ware? Usually it’s not the tool or the process. It’s whether someone actually believed it mattered enough to do the harder work of changing how people work.
That requires leadership that understands implementation isn’t project management. It’s culture change. Culture change isn’t something you buy from a consultant. You build it, one person at a time, with patience and intention.
Leave a Reply