The Real Cost of a Bad ServiceNow Implementation

The original implementation invoice looks big. In our experience, it is usually the smallest line item in the total cost of a poor ServiceNow delivery.

The rest of the cost is distributed across the organisation in ways that are difficult to attribute but easy to observe: the service desk workarounds that have become process, the modules that are licensed but not used, the IT team that has to manually reconcile data that should be automatic, the upgrade that keeps getting deferred because nobody knows what it will break.

Where the money actually goes

Re-work. The most visible cost. A platform delivered without proper architecture review typically requires significant remediation within two to three years. The customisations that seemed reasonable at the time create upgrade barriers. The data model that worked for the initial scope does not work when the platform expands. The average remediation engagement we see costs between forty and eighty percent of the original implementation, for a platform that still does not work as well as it should.

Unused licences. ServiceNow licences are not cheap. Platforms implemented without a clear adoption strategy routinely have modules that are in scope and licensed, but that the business never actually used. We have seen clients paying for five years of licences on modules that were configured but never put in front of users, because nobody had the architectural conversation about what adoption actually required.

Workarounds that became process. This is the insidious one. When a platform does not do what people need it to do, people build workarounds. Then the workarounds become muscle memory. Then they become documented process. Then the platform gets fixed, and nobody uses the fix because the workaround is now habit. The cost of unwinding this is underestimated almost universally.

Deferred upgrades. ServiceNow releases two major versions per year. Staying current is not optional in the long run: older versions lose support, new capability requires current releases, and the gap between your version and current widens with every cycle you skip. A platform delivered without upgrade strategy in scope typically has its first deferred upgrade within eighteen months. After three or four deferrals, the upgrade is a major project in its own right, delivered under time pressure, and carries significant risk.

The three questions to ask before signing

The answers are diagnostic. An SI that cannot name a specific architect, defaults to "we follow upgrade best practice" without elaborating, and describes documentation as a project deliverable rather than a continuous practice is telling you something important.

The compounding problem

Technical debt in a platform context compounds differently from technical debt in a software project. In a software project, the debt is mostly in the code. In ServiceNow, the debt is in the configuration, the data model, the integration architecture, and the customisation layer, and all of them interact.

A bad CMDB makes incident routing unreliable. Unreliable incident routing makes SLA compliance difficult to measure. Difficult SLA measurement makes performance management ineffective. The cascade is real and the cost at each step is real.

Starting well costs more upfront. Not in licence fees, but in the quality of the architectural work. But it is consistently cheaper over a five-year horizon than starting cheap and remediation over the same period.

If you are assessing an existing platform or evaluating a new implementation, we are happy to give you an independent read. Start with a conversation.