Why ITIL experience now matters more than ITIL knowledge

ITIL was never meant to be followed without thinking. It gives direction, not instructions.

Most IT professionals can recite the difference between an incident and a problem. Far fewer can tell you, at 2am with a store estate offline, which of the two they should be working on right now. That gap between knowing the framework and applying it is where service quality is won or lost.

Why "now"?

Older versions of ITIL were built around defined processes. You could, in principle, follow them step by step.

ITIL 4 replaced processes with practices, guiding principles and value streams. ITIL (Version 5) goes further: Transformation now sits in every designation, and the emphasis has moved from running practices well to leading change through them.

A framework built on principles can't be executed like a checklist. Someone has to decide how each principle applies to this organisation, this service and this risk. That decision is judgement, and judgement comes from experience.

Guidance, not a checklist

ITIL helps organisations understand how services create value, make better decisions and keep improving. It doesn't expect a hospital, a retailer and a shipping fleet to run change or incident management the same way.

The certificate proves you know the guidance. Experience is knowing which parts of it matter most on a given Tuesday.

Every service needs one Service Owner

"The service is owned by IT" means nobody owns it.

Every service needs a single Service Owner: one named person accountable for how it performs from start to finish, including the parts delivered by other teams and vendors. The Service Owner doesn't fix every fault personally. They make sure faults get fixed, improvements get funded and someone answers for the outcome.

Here is the test. Payroll misses its SLA because a network team's firewall change failed. Who explains that to the CFO? If three teams point at each other, the service has no owner. The Service Owner is the person who gets the call, and who then makes sure the next firewall change doesn't hurt payroll again.

Restore first, then remove the cause

When a service fails, the first job is to restore it. That is incident management, and speed is the point.

The mistake is stopping there. If email goes down three times in a week, that isn't three unrelated incidents. It is three incidents pointing to one problem, and until someone finds and removes the underlying cause, the fourth outage is already scheduled.

Knowing the definitions is easy. Experience is spotting the pattern early, having the discipline to open a problem record while everyone wants to move on, and turning root cause analysis into actions with owners and dates. Structured problem management is how my teams cut recurring incidents by 40%: not by fixing faster, but by making sure the same failure couldn't happen twice.

Change with the right amount of control

Change is normal. The skill is matching the control to the risk.

• Standard changes are low risk, repeatable and pre-authorised. A routine patch pushed through a tested pipeline shouldn't wait for a board.
• Normal changes carry real risk and need assessment and authorisation proportionate to it.
• Emergency changes have to move fast, but still get recorded and reviewed.

Treat every change as high risk and delivery grinds to a halt. Treat every change as routine and eventually one takes the business down. ITIL 4 renamed the practice from change management to change enablement for exactly this reason: the goal is to help change happen safely, not to stop it.

Deciding which category a change belongs in is a judgement call. A rule can say "database changes are Normal". Only experience tells you that this database change, on a quarter-end weekend, deserves a second look.

Improvement happens every day

Continual improvement isn't a project with an end date. It happens when teams:

• Spot small problems early, before they become incidents
• Make practical fixes instead of waiting for a transformation programme
• Review the results and adjust

A well-maintained knowledge base is a good example. It won't appear on a strategy slide, but in a busy telecom support environment it was one of the main reasons resolution times came down by 35%.

What experience actually adds

Knowing ITIL concepts is the starting point. Experienced practitioners also know:

• When to follow the guidance closely, because the risk is high and the process exists for a reason
• When to adapt it, because following it to the letter would slow the business without making anything safer
• How to measure outcomes, not activity: services available when the business needed them, not tickets closed

That balance can't be memorised for an exam. It is built by running real services, making real calls and living with the results.

Conclusion

ITIL was designed to support good decisions, not replace them. People who understand the purpose behind the guidance manage services better, handle change with confidence and keep improving quality.

In the end, ITIL is about people and about delivering real value.

Want to see where your own service management practices stand? Take the free ITSM maturity assessment.