Useful governance
Visibility of change, understood risk, a rollback plan and awareness of conflicting activity are valuable controls.
Service Management
Don’t do ITIL for ITIL’s sake.
I’ve spent most of my career working under the ITIL framework and I’ve done the training and earned my green badge. My biggest takeaway is simple: the framework should serve the organisation, not become the organisation.
The Detail Trap
More process does not automatically mean more control.
One of the attractions of ITIL is control. Define the process, define the roles, categorise the work, measure it, review it and improve it. All sensible ideas.
The problem comes when organisations keep adding detail in the belief that more process automatically means more control: another approval, another mandatory field, another category, another meeting, another KPI.
Eventually people spend so much time servicing the framework that they have less time to deliver the service. At that point you may not have gained control. You may simply have created more frustration with better documentation.
Purpose Before Process
The process is not the objective.
Incident management exists to help restore service. Change management exists to help make changes while understanding and managing risk. Problem management exists to understand why things keep going wrong and prevent them happening again.
None of those things exist simply so that we can demonstrate that we followed an ITIL process.
If a process isn’t helping people make better decisions, manage risk, restore services faster or improve the experience of the people using those services, it is worth asking what the process is actually achieving.
“Because that’s the process” is rarely a good enough answer on its own.
The CAB Trap
Control the risk, not the paperwork.
Process for process
Every change waiting for a weekly meeting where people approve work they may know little about can create delay without meaningfully reducing risk.
Proportionate control
A low-risk, repeatable change should not necessarily require the same governance as a major infrastructure change capable of taking down a critical service.
Judgement Matters
Not everything needs a process.
Sometimes the answer is simply to let capable people make sensible decisions. Governance should provide guardrails, not remove judgement.
If engineers understand the service and its risks, and have good monitoring, documentation and recovery procedures, the framework should support them rather than make their job unnecessarily difficult.
If people are constantly finding ways around a process just to get their work done, that is worth investigating. The problem might not be the people. The problem might be the process.
RACI
Useful until maintaining the matrix becomes the work.
RACI is another good example of something I genuinely value, but which can quickly become more complicated than the problem it was meant to solve.
At its heart it asks four useful questions: who is Responsible for doing the work, who is Accountable for the outcome, who needs to be Consulted, and who simply needs to be Informed?
That clarity matters. When something goes wrong, one of the most important questions is: who owns this? A simple RACI can remove the silence and finger-pointing that follows when nobody is quite sure.
The trouble starts when the spreadsheet becomes an exercise in its own right. Dozens of activities, twenty teams, every box needing a letter, and meetings debating whether somebody should be Consulted or merely Informed.
If you spend three hours defining who is responsible for something that would have taken twenty minutes to do, that isn’t control. That’s administration.
Accountability
The conversation matters more than the matrix.
For me, the most valuable part of RACI is not the spreadsheet. It is the conversation: who owns this, who has authority to make the decision, who genuinely needs to be involved and who just needs to know?
Having somebody marked A in a spreadsheet does not automatically create accountability. They need to understand that they own the outcome and have enough authority to do something about it. Likewise, putting ten people down as Consulted may simply mean ten people are invited to another meeting.
Used well, RACI removes ambiguity. Used badly, it documents ambiguity in a spreadsheet.
Use the tool when it solves a problem, keep it as simple as possible and question it when the administration starts outweighing the value. Don’t do RACI for RACI’s sake either.
Different Organisations
ITIL does not need to look the same everywhere.
A large enterprise operating critical services has very different requirements from a small technology team running a handful of systems. Trying to implement exactly the same level of governance in both makes little sense.
That does not mean smaller organisations should ignore ITIL. Almost everyone working in IT can take something useful from it: clearer incident handling, distinguishing incidents from problems, impact and urgency, sensible rollback plans, learning from major incidents and understanding that technology ultimately exists to provide a service to somebody.
You do not need to implement the entire framework to benefit from those ideas.
My Takeaway
Take the bits that make you better.
I’m certainly not anti-ITIL. It has influenced how I think about incidents, changes, problems, risk, ownership and what it means to provide a service rather than simply operate technology.
But I have also seen how easily organisations become bogged down in the detail. The pursuit of control can create so much process that people become frustrated by the very framework that was supposed to help them.
Use what helps. Adapt what nearly helps. Question what doesn’t. Apply enough governance to manage genuine risk, and keep asking whether your processes are still delivering value.
ITIL is a framework, not the objective.
Don’t do ITIL for ITIL’s sake.