I've sat in a lot of "lessons learned" sessions at the end of ITSM transformation programs. The language is usually consistent: "We underestimated change management." "The platform rollout went well but adoption lagged." "We need to do more training."
These aren't wrong observations. But they're symptoms, not causes. After 25 years of leading these engagements, I've come to believe that most ITSM transformations fail for a reason that almost nobody says out loud in the debrief: they started in the wrong place.
Failure Mode #1: The platform became the strategy
The most common pattern I see goes like this: the organization selects a platform, signs the contract, and then — under time and budget pressure — the implementation becomes the roadmap. Features get turned on in the order the vendor recommends. Processes get designed around what the tool supports out of the box.
By the time the project closes, IT has a functioning platform. What it doesn't have is an IT operating model designed to serve the business. The platform is live, but the business still calls IT a black box.
"We spent $2M on the platform. Adoption is at 40% eighteen months later. And nobody can tell me whether that's a training problem, a process problem, or a culture problem."
That's a CIO I spoke with recently. The issue wasn't the platform. The issue was that nobody defined what success looked like for the business — before the project started.
Failure Mode #2: Governance without accountability
Every ITSM transformation produces a governance model. RACI matrices get created. Change Advisory Boards get relaunched. Service ownership gets defined — on paper. Then the project ends, the consulting team offboards, and within ninety days the governance model is being quietly bypassed because it doesn't fit how the business actually operates.
The root cause is almost always the same: the governance model was designed for IT's convenience, not for the business it's supposed to serve. It reflected the IT org chart instead of business accountability. It measured compliance with process instead of impact on outcomes.
Real governance is designed around decision rights, not process steps. It answers: who owns this service? Who decides when the process changes? Who is accountable when the experience degrades? Without clear answers to those questions, the governance model is theater.
Failure Mode #3: Maturity scores without a roadmap anyone can execute
This one is subtle. The assessment gets done. Maturity scores are produced. The executive heatmap looks credible. And then the roadmap gets handed off to the IT leadership team — and six months later it's sitting in a SharePoint folder.
The problem is usually sequencing. The roadmap was built to be comprehensive, not executable. It documented what good looks like without answering: what do we do first, with the people and budget we actually have, given the other priorities already in flight?
A roadmap that isn't sequenced for execution isn't a roadmap. It's a list of aspirations with a Gantt chart attached.
The fix isn't complicated — but it requires starting earlier
Every one of these failure modes has the same root cause: the transformation program started with IT's agenda instead of the business's needs. Platform first. Process second. Business outcomes — if at all — somewhere in the appendix.
The organizations that get this right start differently. They spend time at the beginning — before any platform decisions, before any governance design — answering a simple question: what does this business actually need IT to do? Not what IT thinks it should do. What the business needs.
Everything else — platform, process, governance, roadmap — flows from the answer to that question. When you start there, the transformation has a foundation. When you don't, you're building on sand and hoping the platform holds it together.
If any of these patterns sound familiar — or if you're about to kick off a transformation and want to pressure-test the starting point — I'm happy to compare notes.