From Hospital Corridors to Boarding Gates

# ITIL

What ITIL (Version 5) Gets Right About Complexity

July 28, 2026

Farooq Hussain

From Hospital Corridors to Boarding Gates: What ITIL (Version 5) Gets Right About Complexity

A few years ago, I was sitting in a windowless meeting room in Abu Dhabi, trying to explain to a hospital director why a printer outage in radiology was not really a printer outage. The printer was the visible failure. Behind it sat a disrupted patient-scheduling workflow, a vendor SLA that nobody had looked at closely for months, and a nurse who was already dealing with a difficult shift. Our process diagram had a box for the device failure. It had no box for everything surrounding it.

That afternoon has stayed with me. Since then, I have worked through a hospital rollout covering fifteen sites and moved into aviation, where I now run an IT Service Centre supporting Level 1 and Level 2 operations at our home base and several outstations. The industries are very different, but the same truth keeps showing up: service management looks much cleaner on paper than it feels when you are responsible for it in real time.

So when ITIL (Version 5) began leaning more openly into Complexity Thinking and referencing Cynefin, I did not immediately welcome it. I was cautious. I have sat through enough workshops where a framework from another discipline is added to a slide deck because it sounds intelligent. But the more I considered it against actual operational experience, the more useful it became. It did not feel like a new theory being imposed on the work. It felt like a name for something experienced practitioners had already learned, usually the hard way.

When a printer issue is not really a printer issue

Traditional ITSM training teaches us to sort work into incident, problem, change and request. Those categories matter. They bring order, especially when a service desk is still maturing. The difficulty comes later, when the organisation becomes more connected and the categories start giving us a false sense that every issue will behave predictably once it has been labelled.

Across fifteen hospital sites, each location had its own operating rhythm, local habits and informal workarounds, while all of them were expected to follow one target operating model. In aviation, the same tension appears in a different form. A ticket raised at 2 a.m. from an outstation may look routine when it enters the queue. By boarding time, the same issue can involve airport operations, application support, a local vendor and the turnaround team, particularly if it touches check-in, baggage or flight departure activities. The ticket did not simply become larger. The environment around it changed what the issue meant.

For me, that is one of the quieter strengths of ITIL (Version 5). It gives practitioners permission to call this complexity instead of describing it as a badly managed incident. Not every situation repeats in the same way, even when the symptoms look familiar. Recognising that early can prevent a team from applying a perfectly good process to the wrong kind of problem.

Putting Cynefin against a real operational metric

The first time someone brought 'domains of complexity' into a service review, I was doubtful. The language felt theoretical, and the meeting was dealing with very practical pressure. Then we applied it to a metric I was actually accountable for, and it became much less abstract.

Our abandoned call rate had been rising and was sitting close to one in five callers hanging up before reaching an agent. The natural reaction in the room was to reach for one obvious lever: add headcount, reduce handling time or push agents harder against a target. We made more progress when we stopped and asked whether the number represented one problem at all. Part of it was complicated but understandable. We could see a bottleneck, introduce a proper callback programme and track a small group of supporting KPIs so leadership could see whether the change was working. Another part was genuinely less predictable. Call volumes shifted by time, location and operational event, and some of those patterns were driven by activity outside the service desk. No staffing formula, on its own, was going to remove that variation.

Saying that out loud mattered. People understandably wanted one cause, one action and one improving number. Separating the solvable bottleneck from the behaviour we needed to observe gave us a more honest plan than forcing both into the same corrective action.

Where AI makes the job harder, not easier

There is a common claim that AI will simplify service management. My experience so far is almost the reverse. AI can expose patterns and anomalies much earlier, but that often means complexity arrives at the team faster than the team is prepared to interpret it.

A tool that spots an unusual call pattern before a manager notices it can be genuinely valuable. But the tool still cannot own the operational judgement. Someone has to decide whether the signal points to a known situation with a proven response, or whether the team is seeing something new and should slow down before acting. A predictive alert without that judgement is still just an alert. It may arrive earlier and look more sophisticated, but it can create the same confusion as any other poorly understood notification.

Most conversations I hear about AI in ITSM still focus on automation: routing tickets, answering common questions, triggering self-healing scripts and reducing manual effort. All of that has value, but it is only part of the opportunity. The more interesting area is behavioural signal - noticing how people are experiencing or using a service before the issue becomes a ticket. That is harder work. It also depends on the team being able to recognise what kind of situation it is looking at. Otherwise, more signals simply create a larger queue of things nobody fully understands.

What this looks like on the service floor

A complexity-aware service desk does not need agents to become management theorists. It starts with a very practical habit: before reaching for the script, ask whether this is a known pattern or whether something about it feels different. That one question has improved escalation quality more than several rounds of script rewriting, because it changes when people pause and when they ask for help.

It also changes the tone of leadership reporting. Not every movement in a metric has a neat root cause waiting to be discovered. Sometimes the most responsible update is that a pattern has emerged, the leading indicators are being watched and the team does not yet have enough evidence to claim a cause. That may be less satisfying than a confident sentence on a slide, but it is usually more useful.

The same thinking should shape how we assess new tools. The important question is not only whether a product detects anomalies. It is whether it helps the team understand and triage those anomalies quickly enough to respond well. A platform that produces ten intelligent alerts a day but gives no support in distinguishing routine variation from genuine concern has not reduced complexity. It has simply presented the complexity in a newer interface.

Different sectors, same operational instinct

Healthcare and aviation look very different from the outside, but the operational pressure has familiar features: human safety, close scrutiny, multiple dependencies and very little tolerance for 'we will fix it in the next sprint.'

Healthcare taught me that a clinician trying to recover an IT service during a shift cannot be treated like an office user raising a routine ticket. Aviation taught me how quickly a small disruption can travel across functions and locations instead of staying where it started. I would not describe either industry's playbook as universally correct. What travels well between them is the instinct to recognise when a situation needs a known fix, when it needs deeper analysis and when it needs careful observation before anyone pretends to have the answer. That, to me, is close to the practical lesson behind ITIL (Version 5)'s treatment of complexity.

For practitioners who are newer to this

Keep the checklists. Most service-management work still benefits from clear process, disciplined ownership and well-designed SOPs. The mistake was never using standard procedures. The mistake is assuming that every situation qualifies for one simply because a ticket has been opened.

Learn to notice when you have moved beyond checklist territory. That judgement will not come from reading one section of a manual. It comes from reviewing incidents over time, noticing where familiar responses stopped working and being honest about the moments when the team understood less than it first assumed.

Do not leave your industry experience at the door either. Regulatory pressure, customer expectations, safety concerns and local operating realities are not distractions from complexity thinking. They are what make it real. Without that context, complexity becomes another attractive diagram that disappears as soon as the meeting ends.

ITIL has always been most useful when it reflects how capable practitioners actually work, rather than asking them to behave as though operations are cleaner than they are. This version feels more comfortable acknowledging uncertainty. It recognises that good service management is not always about driving an issue through a perfect flowchart. Sometimes it is about knowing where the flowchart stops helping.

That is not an argument for throwing away incident, problem, change or request management. Those practices still carry most of the day-to-day workload, and they should. Complexity Thinking does not replace disciplined process. It helps us recognise the smaller but important group of situations that do not fit neatly, so we can stop forcing them into a shape that makes reporting easier but decision-making worse.

I would be interested to hear how practitioners in other sectors handle this, especially those working in regulated environments where a service interruption is rarely only an IT issue and almost never stays inside one team.

Enjoyed this post? Join the conversation by leaving a comment or sharing your thoughts below, we’d love to hear your experiences and perspectives. Don’t forget to explore our upcoming events for more opportunities to learn and connect, and visit the forum to continue the discussion.