I’ve sat in enough implementation meetings to recognise the moment everything goes wrong.

It happens early. Usually in the first conversation.

We talk about implementing a piece of technology. We discuss features, modules, timelines. We debate technical capabilities and integration points. What we don’t talk about is how this enables the business, how it serves the CIO’s two-year vision, or how it aligns with the CEO’s strategy.

The value aspect is missing from day one.

When that happens, the technology gets treated as an expense instead of a value generator. The entire implementation becomes a cost to minimise rather than an investment to maximise.

The Elephant in the Room

I worked with a customer recently where we were implementing ITOM Visibility. The Engagement Manager (EM) was delighted with the proposal. However his leadership wouldn’t sign off the budget.

The leadership saw what was missing. The Engagement Manager didn’t. Neither did the implementation partner.

We were talking about technical capabilities. Discovery modules. Data collection. Infrastructure visibility. All perfectly valid technical objectives.

Nobody asked what business objective we were trying to solve.

When I do ask that question in implementation meetings, the response tells me everything I need to know. If I see question marks around the room, I’ve found the elephant everyone’s been ignoring. If people can articulate clear business objectives, we’ve got a fighting chance.

The EM in that meeting was optimising for getting the product he needed. The technical capabilities. His leadership was optimising for something entirely different—business outcomes that would justify the investment.

The Two-Part Failure

This disconnect happens in two places.

First, there’s a communication breakdown. Top-down communication about what leadership wants to achieve doesn’t connect with bottom-up reporting of outcomes and KPIs. The EM hears “we need better infrastructure visibility” when leadership is actually saying “we need to reduce operational risk to support our expansion strategy.”

Second, there’s a measurement problem. Organisations struggle with how value gets generated and measured.

The data backs this up. 70% of organisations struggle with KPI alignment. Even more damning: only 40% regularly review their IT KPIs, meaning metrics stay fixed whilst business objectives evolve.

You’re measuring theatre—tracking what’s easy rather than what matters.

What Gets Measured (And What Doesn’t)

When organisations do attempt to measure value from ServiceNow implementations, they miss the point entirely.

They don’t measure how ServiceNow enables the business to do more. They don’t track how operational improvements translate into actual business outcomes. They measure ticket resolution times without asking whether faster ticket resolution enabled the sales team to close three additional deals that quarter.

The shift from ROI to ROO (Return on Objectives) acknowledges this fundamental problem. Traditional ROI calculators fail to capture the full value of tech investments designed to deliver long-term transformation.

You can’t measure improvement without a starting point. If you didn’t document manual processing times or error rates before implementation, assessing ROI becomes guesswork. Most organisations are measuring success against a baseline that never existed.

The Worldview Chasm

Here’s the uncomfortable truth: only 20% of IT executives align with the expectations set by their business counterparts regarding the strategic use of IT.

This isn’t a communication problem. It’s a worldview chasm.

Business executives expect IT to enable disruptive transformations in business models. IT executives focus on modernising existing business capabilities. The EM is optimising for technical capabilities whilst leadership seeks business transformation.

You’re solving different problems entirely.

49% of CIOs believe IT and business teams working in silos affects IT’s ability to maximise value for the business. Technology decisions get made in isolation, without proper consideration of broader business objectives. The result? Investments that are technically sound but strategically hollow.

The Hidden Costs of Getting It Wrong

Failed implementations don’t just waste the initial investment. They actively drive organisations backwards.

83% of employees use unauthorised software solutions when official tools prove difficult to use. Organisations spend an additional £££ per employee annually on redundant tools and remediation efforts when primary systems like ServiceNow go underutilised.

The platform designed to streamline operations actually multiplies chaos when implementation misses the mark.

Organisations with poor enterprise software adoption experience data quality degradation of 40–60% compared to those with strong adoption programmes. You’re making multi-million pound decisions based on fundamentally flawed information, perpetuating inefficiencies rather than addressing them.

The platform promised strategic insights. Instead, it delivers confidence in bad data.

The Adoption Penalty

Organisations with low adoption rates experience:

• 65% higher ticket volumes related to platform usage questions
• 40% longer resolution times due to inconsistent process adherence
• 3x higher escalation rates to specialised support teams

ServiceNow’s revenue continues to soar—annual revenue in 2024 was $10.984 billion, reflecting a 22.45% year-over-year increase. This masks the value erosion happening inside customer organisations where implementations fail to deliver on their promise.

The Customisation Trap

ServiceNow deployments often result in higher platform customisation due to lack of programme governance, poor architecture design, complex business requirements, and pressure from users to replicate legacy platform capabilities.

The result? Poor ROI realisation, increased upgrade cycles, poor platform performance, and increased total cost of ownership.

The real problem isn’t custom code.

It’s custom code with no owner, no context, and no lifecycle. Perfectly reasonable customisations cause outages or upgrade failures simply because nobody remembers why they existed, what problem they originally solved, or whether they’re still relevant.

The risk isn’t the code itself. It’s the absence of accountability.

This reveals the deeper governance failure: organisations treat implementation as a project endpoint rather than the beginning of a lifecycle.

The Consultant Conundrum

Implementation partners often perpetuate these problems rather than solve them.

Verified reviews repeatedly call out a steep initial configuration curve and heavy customisation to match real-world processes. Users complain that “implementation has been poor because we used a third party to help set up things, and it’s very basic.”

Organisations discover additional licence requirements after implementation. Opaque pricing means some organisations get asked for fees “they came up with AFTER we implemented with them and for things we’ve had in production for years.”

The consultant in that ITOM Discovery meeting was happy to talk about technical implementation. He had no incentive to ask about business objectives. His success metrics were project completion and technical deployment, not business value realisation.

The Dangerous Middle Ground

When I ask “what business objective are you trying to solve?” the responses fall into two categories.

Some people recognise they don’t know. These conversations turn productive quickly. We take it offline, create those objectives, build alignment between technical capabilities and business outcomes.

Others think they know and carry on with vague information.

This second group is more dangerous than the blank stares. They have just enough clarity to be confident but not enough specificity to be useful. They talk about “improving efficiency” without defining what efficiency means or how they’ll measure it. They mention “better user experience” without articulating which users or which experiences matter most.

They’re fooling themselves about having clarity, and the implementation proceeds on that false foundation.

What Success Actually Looks Like

Successful implementations start with a simple question that almost never gets asked: what business objective are you trying to solve?

Not what technical capabilities do you need. Not which modules should we implement. Not how quickly can we go live.

What business objective are you trying to solve?

If that question creates a question mark in the room, you’ve found the work that needs to happen before any technical implementation begins.

The organisations that get this right don’t measure how many tickets get resolved. They measure how ServiceNow enables the business to do more. They track how operational cost reductions translate into competitive advantages. They connect improved user experience to employee retention or customer satisfaction scores.

They treat the platform as a value generator, not an expense to minimise.

The Path Forward

The fault doesn’t lie in ServiceNow’s capabilities. The platform can deliver extraordinary value when implemented with clear business objectives and proper governance.

The fault lies in how we approach implementation.

We optimise for technical deployment when we should optimise for business enablement. We measure what’s easy when we should measure what matters. We treat implementation as a project when we should treat it as a lifecycle.

The EM who was happy with that ITOM Discovery proposal wasn’t wrong to want better infrastructure visibility. He was wrong to stop there, to assume technical capabilities would automatically translate into business value.

His leadership knew better. They saw the missing piece.

The question is whether you see it too.

Before your next ServiceNow implementation conversation, ask yourself: can you articulate the specific business objective this technology will solve? Can you explain how technical capabilities will translate into measurable business outcomes? Can you connect the dots between platform features and strategic goals?

If you can’t, you’re not ready to implement.

You’re ready to have a different conversation first.