If you read enough ITSM blogs and vendor content, you could be forgiven for thinking that the big decision is which framework or tool to implement next: ITIL, ISO 20000, USM, VeriSM, ServiceNow vs the rest, and so on. In practice, those choices matter far less than one prior decision:
ITIL, ISO 20000 and USM play different and complementary roles:
Defines what a Service Management System must cover if you want to claim you have an effective, certifiable SMS.
Provides detailed practice guidance for processes and capabilities – how to design and run incident management, change enablement, problem management, etc.
Operates at the management‑system level: a very lean structure and a small set of generic processes to manage services across domains.
All of these are useful. The problem arises when one of them becomes the whole story. I am often called in to "fix ITIL." In almost every case, the problem is not ITIL itself. The problem is that ITIL was "implemented" – often enthusiastically – without first deciding what the organisation's own management system should be.
You will almost certainly over‑engineer.
You will almost certainly simplify.
Not everyone will agree with that – especially tool vendors and training providers – but it matches what I see on real IT shop floors.
The same logic applies to ISO certificates. ISO 20000 and ISO 27001 can absolutely be valuable. They codify good management‑system practice and encourage continual improvement. They also bring competitive and contractual benefits in some sectors.
But when "get the certificate" becomes the main objective:
Documentation is created for auditors rather than for practitioners.
The SMS is over‑specified on paper and under‑used in reality.
Energy is burned on short‑term audit readiness instead of long‑term system health.
Build something that actually works for your organisation.
Validate and refine that system against established standards.
Evidence that your SMS is robust – not as the reason it exists.
One understandable reaction to audits and incidents is to standardise everything. Central teams start writing very detailed processes, decision trees and templates. Tools become heavily customised to enforce uniform workflows. On slides, it looks beautifully controlled.
Product and platform teams quietly bypass central processes when they can.
Security creates its own "shadow workflows" to stay fast.
Local leaders feel constrained and stop engaging with the central SMS.
A healthy Service Management System is opinionated on what must be standard and modest about the rest.
- Service definitions
- Risk principles
- Change categories
- Major‑incident flow
- Supplier responsibilities
- Evidence requirements
- How individual teams structure their backlogs
- How they run retrospectives
- Which internal tooling they prefer
…as long as they respect SMS guardrails.
USM and similar methods are useful here precisely because they simplify. Fewer generic processes, clearer roles, smaller rule sets. The real discipline lies in keeping the SMS small and saying no when every new initiative wants to add its own special process.
Finally, a word on outside help – including my own.
You rarely need an external consultant to tell you that "ITSM is important" or that "NIS2 is serious." You probably already know that. Where an experienced advisor helps is in shortening the path from insight to a working SMS.
Has exposed that there is no coherent story about how services and risks are managed.
A ServiceNow or similar platform has grown organically and become difficult to govern.
More product teams, more cloud, more outsourcing has made old processes and roles unworkable.
Make your implicit SMS visible: scope, roles, routines, gaps.
Agree how explicit and how ambitious your SMS should be over the next 12–24 months.
Co‑create a one‑page SMS charter, a lean role model, a handful of cross‑cutting routines and clear mappings to tools and controls.
Support your first SMO cycles and management reviews, then step back as internal capability grows.
If you've read this far through the "Service Management System Discovery" series, you already have most of the concepts you need. The next step is simply to ask, with your own leadership team:
"If we had to explain our Service Management System on a single page to our board tomorrow, what would it say – and who would sign it?"
That is where the real journey starts.
The pain of ITSM without an SMS
What an SMS is and how it relates to your operating model
Why the SMS becomes the backbone of governance and compliance
Avoiding framework religion and building a living SMS
This article is part 4 of 4 in the "Service Management System Discovery" series. In part 1 we looked at the pain of ITSM without an SMS. In part 2 we defined what an SMS is and how it relates to your operating model. In part 3 we showed why it becomes the backbone of governance and compliance. This final part is deliberately more opinionated: how to avoid framework religion and build a living SMS that fits your organisation – and where an external advisor helps.