Continual improvement is one of the most referenced ideas in ITIL v4 and one of the least consistently practised in real IT organisations. If your team fixes incidents, ships changes, and hits SLAs but never steps back to ask whether the whole system is getting better, you are running in place. This post walks through what a working continual improvement practice looks like, how to structure it, and what separates teams that improve steadily from those that hold a retrospective once a year and forget about it.
What Continual Improvement Actually Means in ITIL v4
ITIL v4 treats continual improvement not as a project or a quarterly review but as a permanent, embedded practice that runs alongside every other service management activity. The idea is that every team, every process, and every service should have a regular mechanism for identifying where it falls short and acting on that gap.
The ITIL Continual Improvement Model gives you a seven-step loop:
- What is the vision? Anchor improvement to a business outcome, not a tool or metric.
- Where are we now? Establish an honest baseline using data.
- Where do we want to be? Define a measurable target state.
- How do we get there? Plan specific actions with owners and deadlines.
- Take action. Execute the plan in a controlled way.
- Did we get there? Measure results against the target.
- How do we keep the momentum going? Feed findings back into the next cycle.
The model sounds straightforward, but most organisations stall between step two and step three. They collect data, hold a meeting, and never commit to a target state with a named owner. The result is a backlog of good intentions rather than a register of active improvements.
The Difference Between Improvement and Fire-Fighting
A common trap is labelling reactive fixes as continual improvement. Patching a server after an outage is incident response. Analysing why that class of outage keeps recurring and redesigning the patching process is continual improvement. The distinction matters because one stops the bleeding and the other changes the underlying condition.
Building a Continual Improvement Register
The most practical tool in any continual improvement practice is a register — a living list of identified improvement opportunities, their current status, priority, owner, and expected outcome. Without a register, improvements compete informally for attention and the loudest voice wins.
A well-maintained register should capture:
- A short description of the improvement opportunity
- The practice or service it relates to
- The business or operational justification
- A priority rating based on impact and effort
- A named owner accountable for driving it forward
- A target completion date or review milestone
- The current status and any blockers
The register is not a wish list. Every item on it should have been assessed and either accepted for action, deferred with a reason, or rejected. Items that sit in an ambiguous state for months signal that the governance around improvement is weak.
Who Owns the Register
In smaller IT teams the service desk manager or IT manager often owns the register directly. In larger organisations a dedicated service improvement manager or a practice owner takes responsibility. What matters more than the job title is that someone has a standing agenda item to review the register regularly — at minimum monthly — and has the authority to assign work and escalate blockers.
Linking Improvements to Metrics
Every item in the register should trace back to at least one measurable indicator. If you cannot describe how you will know the improvement worked, the item is not ready to act on. Common indicators include mean time to resolve, first-contact resolution rate, change success rate, SLA compliance percentage, and asset data accuracy. Your service desk metrics post is a good companion reference for choosing the right measures.
Where Improvement Opportunities Come From
Continual improvement does not happen in a vacuum. It depends on a steady flow of input from across the IT operation. The most reliable sources include:
- Post-incident reviews, especially after major incidents, which surface process gaps, tooling failures, and communication breakdowns
- Problem records, which by definition represent recurring or unresolved issues that need a systemic response
- Customer satisfaction surveys and ticket feedback scores, which reveal where users experience friction that metrics alone do not capture
- SLA breach analysis, which shows where current targets are being missed and whether the root cause is process, resource, or tooling
- Change post-implementation reviews, which identify whether changes are delivering their intended outcomes
- Audit findings from IT asset audits or compliance reviews, which expose gaps in governance and controls
- Staff feedback from frontline service desk agents, who often see process failures before management does
The key is creating formal channels for each of these inputs to reach the improvement register rather than disappearing into email threads or verbal conversations.
Prioritising and Executing Improvements
Not every improvement can happen at once. Prioritisation is where many programmes falter because teams try to apply a purely objective scoring model to what is ultimately a judgement call. A simple two-axis approach — impact on service quality or cost versus effort to implement — is enough to create a workable priority order for most teams.
High-impact, low-effort improvements should move quickly. High-impact, high-effort improvements need a proper plan with milestones. Low-impact improvements should be reviewed periodically but should not consume significant capacity.
Running Improvement Sprints
One effective pattern is to run short improvement sprints alongside normal operations. A sprint of two to four weeks focuses the team on a small number of improvements with a defined scope. At the end of the sprint the team reviews what changed, measures the result, and decides whether to continue, adjust, or close the item.
This approach works well because it creates a rhythm. Improvement becomes a regular activity rather than a special event. It also limits the risk of over-engineering a solution before you have validated the approach.
Avoiding the Common Failure Modes
The most common reasons continual improvement programmes lose momentum:
- No dedicated time. Improvement work competes with operational demand and loses every time unless protected capacity is allocated.
- No visible outcomes. If the team never sees evidence that improvement work changed anything, motivation drops. Communicate results even when they are modest.
- Scope creep. Starting with a large, complex improvement initiative before building the habit tends to produce exhaustion rather than progress. Start small and build confidence.
- Lack of leadership support. Improvement that is only driven bottom-up rarely survives the first budget pressure. Senior IT leaders need to treat the register as a management tool, not a team activity.
Embedding Improvement Into Everyday ITSM Practices
Continual improvement should not feel like a separate workstream. The goal is to make it a natural part of how your team operates every practice.
In incident management, this means reviewing recurring incidents monthly and feeding patterns into the problem management process rather than just closing tickets.
In change management, it means treating every failed or unplanned change as an input to the improvement register, not just a statistic.
In service request management, it means analysing request volumes to identify automation or self-service opportunities that reduce manual effort.
In knowledge management, it means tracking which articles are used, which are outdated, and which gaps in the knowledge base are driving repeat contacts to the service desk.
In asset management, it means using discovery data from tools like Odysseus to identify gaps between what your CMDB records and what is actually on the network, then improving the processes that keep asset data current.
The point is that every practice generates signals. Continual improvement is the mechanism for turning those signals into action.
Measuring the Improvement Practice Itself
It is worth applying the same discipline to the improvement practice that you apply to everything else. Useful measures include the number of items in the register, the percentage closed within their target date, the average cycle time from identification to closure, and the measurable outcome achieved per closed item. If these numbers are not moving in the right direction, the practice itself needs improving.
Key Takeaways
- Continual improvement is a permanent ITIL v4 practice, not a project or an annual review.
- A continual improvement register gives every opportunity a visible status, owner, and measurable target.
- Inputs should come from incident reviews, problem records, SLA analysis, audits, surveys, and staff feedback.
- Prioritise by impact and effort, protect capacity for improvement work, and run short focused sprints to build momentum.
- Embed improvement into every ITSM practice so it generates a constant flow of opportunities rather than depending on occasional retrospectives.
- Measure the improvement practice itself and treat weak results as an improvement opportunity.
TIKTING includes a built-in continual improvement register that connects directly to incidents, problems, changes, and service requests, so improvement opportunities are captured in context rather than in a separate spreadsheet. Odysseus asset discovery feeds asset accuracy data into TIKTING, making it straightforward to identify and track improvements to CMDB hygiene and inventory processes. If you are evaluating whether your current platform supports a genuine improvement practice, our ITSM tool selection guide is a useful starting point.
