Every practice on this ITIL trail — incidents, problems, changes, service levels — describes how to run things as they are. Continual improvement is the practice that refuses to leave them that way. It sounds like the softest topic in the framework; it's actually the survival mechanism. Organisations don't fail because their processes were never good — they fail because processes designed for one era keep running, unexamined, into the next. Improvement is the anti-fossilisation loop.
The model: seven questions in a circle
ITIL's continual improvement model is a sequence of questions so sensible they feel obvious — which is precisely why skipping them is so common:
- What is the vision? — anchor to what the business is trying to achieve, so you improve toward something.
- Where are we now? — an honest baseline, measured, not remembered. Skip this and you'll never prove anything improved.
- Where do we want to be? — a specific, measurable target. "Better" is not a destination; "first-contact resolution from 55% to 70% by Q3" is.
- How do we get there? — the plan, preferably iterative (small steps, feedback — the guiding principles echoing again).
- Take action — the step organisations are surprisingly good at skipping after a beautiful planning phase.
- Did we get there? — measure against the baseline from step two. This is where that baseline pays for itself.
- How do we keep the momentum? — embed the gain so it survives staff turnover and next quarter's crisis, then circle back to the start.
If the shape looks familiar, it should — it's the scientific method wearing a lanyard, and it's deliberately fractal: the same loop works on a ticket category, a process, or an entire department.
The tool that makes improvement real rather than aspirational: the continual improvement register — a simple, visible list of improvement ideas, each with a source, an expected benefit, a size, and an owner. Its power is mundane: ideas raised in retrospectives and corridor conversations stop evaporating; they queue, get prioritised against each other, and — because the register is visible — someone eventually asks why nothing's moved. An organisation's real improvement culture isn't in its mission statement; it's in whether this list exists and whether items ever leave it completed.
Two closing truths from the field. First, improvement needs protected capacity: teams at 100% firefighting utilisation improve nothing, forever — the time has to be deliberately carved out, which is a management choice, not a scheduling accident. Second, improvement is everyone's job in ITIL 4's telling, and that's not a platitude: the service desk analyst who notices the same fault weekly and raises a problem, or drafts the missing knowledge article, is doing continual improvement without a steering committee in sight. The loop belongs to whoever's paying attention.