Updated September 2026.
Most transformation budgets get built backward. A leadership team decides the service desk needs to change, a vendor demo goes well, a platform gets shortlisted, and somewhere in a business case the phrase “digital transformation” appears next to a number with six zeros. What almost never appears is a clear, evidenced answer to a simpler question: how mature is the ITSM practice today, and is a new platform even the right lever to pull?
An ITSM maturity assessment answers that question before the money moves. It is not a prerequisite step for its own sake. It is the difference between funding a fix for the problem you actually have and funding a fix for the problem a vendor’s slide deck described.
What skipping the assessment actually costs
The idea that most transformations fail is repeated so often that it has become received wisdom, usually attached to a “70%” figure. That number is worth being skeptical of. A widely cited version traces back to a 2015 McKinsey article about change management in general, not digital transformation specifically, and independent reviews of the underlying research have found no solid empirical basis for it as a universal rate.
The real research is more specific, and more useful. McKinsey’s 2018 global survey of 1,793 executives found that only 16% of digital transformations both improved performance and sustained that improvement over time. Boston Consulting Group’s 2020 study of transformation outcomes found a similar pattern from a different angle: about 30% of transformations fully met their objectives, 44% created some value but missed their targets, and 26% delivered little or nothing.
Read together, those numbers say something an assessment is built to catch: most transformation spend does not fail outright, it underperforms. Money goes out, a platform goes live, and the organization ends up with 30 to 70% of what the business case promised, because the plan was built on assumptions about current maturity rather than a measured baseline.
What “spending before assessing” looks like in practice
It rarely looks reckless from the inside. It looks like ordinary sequencing:
- A new ITSM platform gets purchased because the current one is old, without first confirming whether the problem is the tool or the process running on top of it.
- A major process redesign gets scoped around best-practice frameworks, without checking whether the organization’s data and governance can actually support the new process on day one.
- An AI or automation layer gets added to incident or request management, on top of ticket data and categorization that nobody has validated in years.
Each of those decisions can be reasonable on its own. The problem is that none of them started from a shared, evidenced picture of where the organization actually stands. A maturity assessment is what produces that picture, scored across process design, tooling and automation, data quality, governance, and culture and adoption, rather than through the process versus tooling versus data versus governance versus culture and adoption debate that otherwise happens informally in a steering committee meeting.
We cover how to actually run that scoring exercise, dimension by dimension, in What Is an ITSM Maturity Assessment? A Practical Framework (+ Scorecard). This post is about the business case for doing it before, not after, the budget is set.
Three ways money gets wasted without a baseline
Overbuying for a process that isn’t ready
Enterprise ITSM platforms are built to support mature, well-defined processes: consistent categorization, clean CMDB relationships, defined approval chains. An organization at an early maturity stage that buys a top-tier platform is paying for automation and analytics capability that has nothing reliable to automate or analyze yet. The platform is not wrong. The sequencing is.
Underbuying, or misdirecting, for a process that already is
The opposite failure is just as common and less talked about. An organization with genuinely mature incident and change processes sometimes spends its transformation budget on more process documentation or another round of consultant-led workshops, when what would actually move the needle is tooling, integration, or headcount. Without a baseline, it’s hard to tell which fix a given team actually needs.
Fixing the wrong layer entirely
The most expensive version of this shows up with AI and automation initiatives. Generative and agentic AI features are being layered onto service desks at a rapid pace, and most of them are only as good as the ticket data, categorization, and knowledge base they read from. An organization that funds an AI pilot before addressing data quality is very often funding a more articulate version of the same underlying problem.
What a maturity assessment gives a budget conversation that a business case alone doesn’t
A vendor business case is built to justify a purchase. A maturity assessment is built to describe a starting point. The distinction matters because it changes what gets funded first. Instead of “we need to modernize ITSM,” the conversation becomes specific: process design is at a defined stage, tooling is ahead of it, data quality is the actual constraint, and governance has no owner for the gap. That is a fundable, sequenced roadmap rather than a single large ask, and it gives finance and IT leadership a shared reference point to check progress against once money has actually been spent.
Sequencing the assessment into the budget cycle
In practice, this does not need to add months to a project timeline. A focused maturity assessment, covering the dimensions above with real evidence rather than a self-scored survey, typically runs a few weeks. That is a small delay against a transformation budget that will be spent over a year or more, and it changes what that budget actually buys.
The sequencing that tends to work is straightforward: assess first, using evidence rather than opinion, to establish where each dimension actually stands. Scope the roadmap second, prioritizing the dimension with the largest gap to target state rather than the dimension a vendor happens to sell a product for. Then build the business case for spend against that roadmap, so the number attached to the project is justified by a measured gap rather than backed into from a platform’s list price.
What a completed assessment roadmap actually looks like
A useful way to picture the output is a five-point scorecard rather than a single grade. Process design gets scored on how consistently defined workflows are actually followed, not just documented. Tooling and automation gets scored on fit for the current process, not on feature count. Data quality gets scored on how much of the CMDB, ticket categorization, and knowledge base can be trusted without manual verification. Governance gets scored on whether policies have an accountable owner and an enforcement mechanism, rather than existing only as a wiki page. Culture and adoption gets scored on whether teams actually use the defined process under pressure, which is when most organizations quietly revert to informal habits.
A typical mid-size enterprise beginning a transformation conversation might score reasonably well on tooling, since most have invested in a modern platform at some point, while scoring meaningfully lower on data quality and governance. That pattern, tooling ahead of the data and governance underneath it, is common enough that it is worth checking for specifically before assuming the platform is the constraint. The roadmap that comes out of the assessment ranks these gaps by size and by cost of inaction, so the budget conversation starts from the largest gap rather than the easiest one to sell internally.
Where DesQcon fits
DesQcon runs ITSM maturity assessments as tool-agnostic, evidence-based engagements: process, tooling, data quality, governance, and culture, each scored against a defined model, with a prioritized roadmap rather than a generic scorecard. We are not paid by any platform vendor to recommend their product, so the roadmap reflects what your organization’s data actually shows, not a shortlist a reseller handed us.
If a transformation conversation is already underway in your organization, the most useful step available right now is also the one that costs the least: find out where you actually stand before the rest of the budget gets committed.
See our ITSM Maturity Assessment Methodology for how we score people, process, tools, automation, AI, and governance before you commit budget to any transformation initiative.
Frequently asked questions
Do we need an ITSM maturity assessment if we already have an ITIL implementation?
Yes, and it is often more useful there than in an organization starting from nothing. ITIL adoption tells you which processes are documented. It does not tell you how consistently they are followed, how clean the underlying data is, or whether governance actually enforces them. Those are exactly the gaps a maturity assessment is built to surface.
How long does an assessment take, and does it delay the transformation project?
A focused assessment across the core dimensions typically takes a few weeks, run in parallel with early planning rather than before it starts. Against a transformation program measured in months or years, it is a small, front-loaded investment that reduces the odds of paying for the wrong fix.
Can we run this assessment internally instead of bringing in outside help?
Internal teams can and do run self-assessments, and a self-assessment is better than none. The tradeoff is objectivity: internal stakeholders are often invested in a particular outcome (a platform they already prefer, a process they built), and evidence-based external scoring tends to surface gaps that a self-assessment quietly rounds up.
Check your own ITSM and ITOM maturity
If this raised questions about where your own organization stands, DesQcon’s ITSM & ITOM Maturity Assessment gives you a structured, evidence-based read on that. Start with a free trial across one process area, or request the full deep-dive assessment across people, process, tools, automation, AI, and governance.
