From Framework Religion to a Living Service Management System
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.
Frameworks are tools; your SMS is the architecture
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:
Are we designing our own Service Management System, or are we outsourcing our thinking to a framework?
ITIL, ISO 20000 and USM play different and complementary roles:
ISO 20000‑1
Defines what a Service Management System must cover if you want to claim you have an effective, certifiable SMS.
ITIL
Provides detailed practice guidance for processes and capabilities – how to design and run incident management, change enablement, problem management, etc.
USM
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.
If you start from ITIL…
You will almost certainly over‑engineer.
If you start from your SMS…
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.
Certification should be a side‑effect, not the main plot
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 for auditors
Documentation is created for auditors rather than for practitioners.
📋 Over-specified on paper
The SMS is over‑specified on paper and under‑used in reality.
⚡ Short-term readiness
Energy is burned on short‑term audit readiness instead of long‑term system health.
NIS2 makes this even more problematic. It creates legal obligations and potential personal liability for management bodies around cybersecurity measures and governance. A thin layer of compliance paperwork on top of a weak or non‑existent SMS is not just fragile; it is a risk in itself.
A healthier narrative
1
Design a lean, living Service Management System
Build something that actually works for your organisation.
2
Use ISO 20000, ISO 27001 and NIS2 assessments
Validate and refine that system against established standards.
3
Treat certificates as evidence
Evidence that your SMS is robust – not as the reason it exists.
Where standardisation helps – and where it hurts
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.
On the ground, it often looks like this:
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.
✅ Standardise
- Service definitions
- Risk principles
- Change categories
- Major‑incident flow
- Supplier responsibilities
- Evidence requirements
🔓 Allow variation
- 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.
Where an external advisor actually adds value
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.
Typical triggers I see:
NIS2 or audit pressure
Has exposed that there is no coherent story about how services and risks are managed.
Platform sprawl
A ServiceNow or similar platform has grown organically and become difficult to govern.
Operating‑model change
More product teams, more cloud, more outsourcing has made old processes and roles unworkable.
In those situations, the work typically looks like this:
Discovery & assessment
Make your implicit SMS visible: scope, roles, routines, gaps.
Strategy & roadmap
Agree how explicit and how ambitious your SMS should be over the next 12–24 months.
Design & documentation
Co‑create a one‑page SMS charter, a lean role model, a handful of cross‑cutting routines and clear mappings to tools and controls.
Implementation & coaching
Support your first SMO cycles and management reviews, then step back as internal capability grows.
The goal is not to make you dependent on an external expert. The goal is to leave behind a Service Management System your organisation owns, understands and can evolve.
The real journey starts here
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.
Part 1
The pain of ITSM without an SMS
Part 2
What an SMS is and how it relates to your operating model
Part 3
Why the SMS becomes the backbone of governance and compliance
Part 4
Avoiding framework religion and building a living SMS