Service management without ITIL dogma: use it as a toolbox, not a religion

ITIL is useful. It is a collection of proven ideas about how you deliver and improve IT services. But ITIL is a toolbox, not a religion. Too many organizations introduce processes because the book says so, not because they deliver anything. The result is administration without purpose and a team filling in forms instead of helping people. This article shows how to use ITIL pragmatically: aimed at outcomes, not at following rules.

The difference between ITIL as a tool and ITIL as dogma

ITIL as a tool means: you have a problem, you take the part out of the box that helps, and you adapt it to your situation. ITIL as dogma means: you introduce the whole framework because it is expected, and you adapt your organization to the book. The first delivers better service. The second mostly delivers overhead.

You can see the difference in the question that comes first. With a tool you ask: which problem does this solve? With dogma you ask: how does ITIL prescribe we do this? The first question keeps you sharp. The second often leads to process nobody needs.

Where process for process arises

Process for process is recognizable. A few signals we often run into:

• Steps nobody can explain. If the team does not know why a field is mandatory, it adds nothing.
• Approvals without a decision. An approval step where the answer is always "yes" is not control but delay.
• Reporting nobody reads. Gathering numbers that never lead to action costs time and delivers nothing.
• Categories nobody uses. A dropdown with thirty options of which three get chosen is ballast.

None of these things make the service better. They give a feeling of order, but they cost your team time that could have gone to users.

Pragmatic service management: steering on outcomes

The core of pragmatic service management is simple: start with the outcome you want, and only then pick the process. A few principles we hold to:

1. Define the outcome first. What needs to improve: speed, quality, predictability, satisfaction? The process follows from that.
2. Take only what contributes. Use the parts of ITIL that bring the outcome closer and leave the rest aside.
3. Keep it as light as possible. Every extra field, every extra step has to earn its place. When in doubt, leave it out.
4. Adapt it to your organization. What fits 3000 people is overkill for 300. Scale the process to your actual situation.

This does not mean you skip the basics. Good registration, clear priorities and working agreements are always needed. It means you stop at what works, instead of ticking off the whole framework.

What we deliberately do not do

We do not introduce ITIL as a goal in itself. We do not build processes that mainly look impressive. And we do not deliver a thick implementation report a team cannot move forward with. What we do is look at the outcome you need and pick the lightest process that achieves it. Service management is a means, not a goal.

That stance fits what we stand for as a partner: achieving more with the same people. Process that delivers nothing actually costs you people. By choosing sharply what you do and do not do, you keep time for the work that counts.

Frequently asked questions

Does pragmatic mean ITIL is not needed? No. ITIL is valuable as a toolbox. The point is that you choose what you take from it, instead of introducing everything because it is there.

How do I know if a process is redundant? Ask what goes wrong if you leave the step out. If nobody can explain that, the step probably adds nothing.

Do we not lose control if we cut processes? No, as long as you keep the basics. Control sits in clear agreements and reliable registration, not in the number of steps.

Want service management that steers on outcomes instead of on following a framework? book a call and we will look together at which process you really need and which you do not.