The Case for Simplicity in ITSM

I have spent the better part of 25 years watching organisations build elaborate service management machinery, and I have noticed something rather consistent: nobody ever sets out to create something complicated. Complexity is not a decision. It is a residue. It accumulates one well-intentioned exception at a time, until the process that was meant to help people now requires a process to explain it. In my opinion, the most underrated skill in ITSM is the willingness to do something simple and then resist the urge to improve it into something nobody understands.

Why Complexity Wins by Default

The path of least resistance leads somewhere expensive

Every workflow I have inherited started life as a sensible idea. The trouble is that sensible ideas compound. Someone asks for an extra approval, someone else wants a custom field, and a third party insists their team needs a separate queue. Each request is individually reasonable and collectively ruinous.

• Additions feel safe, removals feel risky — adding a step rarely gets challenged, whilst removing one invites the question "but what if we need it?"
• Complexity is rarely measured — we track incident volumes and SLA breaches, but almost nobody tracks how many clicks it takes to log a request properly.
• Ownership fragments over time — the person who understood why a step existed has long since left, so the step survives out of sheer institutional politeness.

My experience has been that complexity does not arrive as a flood. It arrives as a slow drip, and by the time you notice the puddle, the carpet is ruined.

What "Simple" Actually Means

Not fewer features, but less friction

Simple is frequently confused with basic, and the two are not the same thing at all. A simple process can be sophisticated underneath; what matters is that the person using it does not have to think about that sophistication.

• Simple for the user, not the architect — the cleverness should sit in the design, not in the daily experience of the person raising a ticket.
• Predictable beats configurable — a process that behaves the same way every time is worth more than one with forty options nobody can remember.
• Fewer decisions at the point of use — every choice you push onto the requester is a choice they can get wrong, and then you own the consequences.

In my opinion, the ITIL 4 guiding principle "keep it simple and practical" is the one most often quoted and least often obeyed. We nod along to it in workshops and then design a twelve-stage approval chain by lunchtime.

The Minimum Viable Process

Start with the smallest thing that works

I have become rather fond of the idea of a minimum viable process, borrowed shamelessly from the product world. The principle is straightforward: design the smallest process that delivers the outcome, put it into use, and only add to it when reality demands it.

• Begin with the happy path — design for the ninety percent of cases that are ordinary, and handle the exceptions as exceptions rather than baking them into the core.
• Earn every step — each stage, field, and approval must justify its existence in terms of an outcome, not a hypothetical risk.
• Add later, with evidence — when you genuinely need more, you will have data telling you so, rather than a nervous guess made at design time.

My preference is always to launch something slightly too simple and let the gaps reveal themselves. A process with obvious gaps gets fixed. A process drowning in pre-emptive controls just gets quietly bypassed, which is far worse because you cannot fix what people are routing around.

Tooling Will Not Save You

A complicated process in ServiceNow is still a complicated process

There is a persistent fantasy that the right platform will absorb complexity on your behalf. It will not. Tools like ServiceNow or JSM are extraordinarily capable, and that capability is precisely the danger. They make it effortless to build something baroque.

• Configuration is not design — the ability to add a field does not mean you have thought about whether the field should exist.
• Automation amplifies whatever you give it — automate a sound process and you get speed; automate a muddled one and you get muddle delivered at scale.
• Every customisation is a future maintenance cost — I am always conscious that today's clever workflow is next year's upgrade headache.

I have seen organisations spend a fortune implementing a platform and then recreate, pixel for pixel, the dreadful manual process they were trying to escape. The tool did exactly what it was told. That was the problem.

Accountability Keeps It Simple

Clear ownership is the best defence against creep

Simplicity is not a one-off achievement; it is a discipline you maintain. The most reliable mechanism I know for maintaining it is unambiguous accountability. When someone owns a process and is answerable for its health, they tend to defend it against unnecessary additions.

• A clean RACI prevents drift — when it is clear who is accountable, requests for changes go through someone with the standing to say no.
• Review for removal, not just addition — most process reviews only ever add. A genuinely useful review asks what can now be retired.
• Measure the experience, not just the metrics — an XLA that captures how the process actually feels to use will surface friction long before an SLA does.

In my opinion, a process without a named, accountable owner is a process that will become complicated. It is not a question of if, merely when, because nobody is standing at the door politely declining the next reasonable-sounding addition.

Where to Start

Practical steps you can take this week

If you are looking at a process that has grown unwieldy, you do not need a transformation programme to begin. You need a willingness to ask awkward questions.

• Map the actual journey — walk through your most common request end to end and count every step, field, and approval a real person encounters.
• Challenge each step once — for every step, ask what breaks if it is removed. If the answer is "nothing obvious", you have found a candidate.
• Pilot the leaner version — change one process, measure the before and after, and let the result make your argument for you.
• Name an owner — give the simplified process a custodian whose job includes keeping it simple, not merely keeping it running.

The goal is not minimalism for its own sake. The goal is a service management practice that people can use without a manual, that survives a platform upgrade without panic, and that does the job it was built to do. Simple is harder than complicated. It is also, almost always, better.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Estimated reading time: 6 minutes