Continual Improvement

Why improvement must be continual

Continual improvement is the recurring, organization-wide effort to make products, services, practices and ways of working better, in steps that are small enough to measure and to undo. In ITIL it is both one of the five components of the ITIL Value System and a management practice in its own right.

Why not one big improvement program every few years? Because the world does not wait. Customers' expectations, technology, regulation and the organization itself keep changing, so a service that was good two years ago slowly becomes inadequate. Large programs also carry large risks: they take long to show results, they are hard to steer, and when they fail, they fail expensively. Small steps give feedback quickly and fit the guiding principle Progress iteratively with feedback.

ITIL deliberately says "continual" rather than "continuous": improvement happens in a recurring series of steps, with pauses to measure and decide, not as one unbroken flow.

The Continual Improvement Model

The Continual Improvement Model is ITIL's structured approach to any improvement, from a small change in one team's routine to a large transformation. Each step is a question. ITIL (Version 5) keeps a seven-step model; the wording below is the familiar ITIL 4 version of the steps.

1. What is the vision? Why are we doing this, and how does it connect to what the organization wants to achieve?
2. Where are we now? An honest, measured picture of the current state: the baseline.
3. Where do we want to be? A concrete target, with the measures that will show we reached it.
4. How do we get there? The plan: which actions, in which iterations, by whom.
5. Take action. Carry out the plan, watching for feedback and adjusting along the way.
6. Did we get there? Measure again and compare with the baseline and the target.
7. How do we keep the momentum going? Embed the change, share the results and start the next improvement.

A worked example: password resets

Mei Chen, the service desk team lead at Kestrel Energy, notices that her agents spend much of their day on forgotten passwords. Here is the improvement, walked through the seven steps.

1. What is the vision? Kestrel wants its staff, including field engineers, to lose as little working time as possible to IT problems, and its service desk to spend its time on issues that need a person.
2. Where are we now? Ticket data from the last three months: on average 1,240 password-reset tickets a month, 31% of all tickets. Average time until the user can work again: 22 minutes.
3. Where do we want to be? Within six months, at most 600 password-reset tickets a month, with no increase in account-takeover incidents.
4. How do we get there? Introduce self-service password reset, protected with multi-factor authentication (MFA). Start with a pilot in the finance department, then roll out in three waves.
5. Take action. The pilot shows that the registration page is confusing, so it is simplified before wave one. Each wave gets a short announcement and a knowledge article.
6. Did we get there? After four months: 790 tickets a month. Progress, but the target is not met. The remaining tickets come mostly from field engineers who never registered an MFA method because they rarely use a laptop.
7. How do we keep the momentum going? Results are shared with the IT management team; MFA registration becomes part of onboarding; a new improvement for field engineers is added to the register, and the cycle starts again.

Note that step 6 did not end in failure. It ended in knowledge: the team now knows exactly which group the next improvement must target. The security side of self-service reset is covered in Passwords and authentication.

Baselines, CSFs and KPIs

Baselines

A baseline is a measurement of the current state, recorded before a change, that later measurements are compared with. Without one, "it feels better" is all you can say. Take the baseline over a representative period (a single quiet week in August is not representative), and write down exactly how it was measured so the comparison is fair.

Critical success factors and KPIs

A critical success factor (CSF) is a condition that must be met for an objective to succeed. It says what must go right, in words. A key performance indicator (KPI) is a metric chosen to show whether a CSF is being met. It says how you will know, in numbers. Each CSF usually has two or three KPIs, and each KPI belongs to a CSF; a number that serves no CSF is probably not worth reporting.

Calculating a KPI against a baseline

The KPI from the worked example, month by month. Besides the reduction from the baseline, it shows how far along the way to the target the team is, which is the more useful number for a progress report.

# KPI: password-reset tickets per month at the Kestrel service desk.
baseline = 1240   # average of the three months before the change
target = 600      # agreed goal, six months after launch

monthly_tickets = {
    "2026-04": 1180,
    "2026-05": 960,
    "2026-06": 820,
    "2026-07": 790,
}

for month, tickets in monthly_tickets.items():
    reduction = (baseline - tickets) / baseline
    progress = (baseline - tickets) / (baseline - target)
    status = "target met" if tickets <= target else "not yet"
    print(f"{month}: {tickets:>5} tickets  "
          f"{reduction:>4.0%} below baseline  "
          f"{progress:>4.0%} of the way  ({status})")

2026-04:  1180 tickets    5% below baseline    9% of the way  (not yet)
2026-05:   960 tickets   23% below baseline   44% of the way  (not yet)
2026-06:   820 tickets   34% below baseline   66% of the way  (not yet)
2026-07:   790 tickets   36% below baseline   70% of the way  (not yet)

The trend flattens after June. That is the signal, in step 6, to look for the reason instead of waiting for the numbers to improve on their own.

Good and bad metrics

A metric is never neutral: once people know they are measured on something, they optimize for it. That makes choosing metrics a design decision with consequences.

• Vanity metrics look impressive but do not support any decision: "12,000 tickets handled this quarter", "4,000 visits to the self-service portal". More tickets handled may simply mean more things broke.
• Goodhart's law, usually summarized as "when a measure becomes a target, it stops being a good measure". If Kestrel rewards agents for a low average handling time, calls get shorter, and problems get passed on unsolved.
• Metrics that drive the wrong behavior. Measuring how fast tickets are closed leads to tickets being closed before the user confirms the fix, to one problem being split into several quick tickets, and to difficult tickets being left at the bottom of the queue.

Ways to keep metrics honest:

• Pair every speed metric with a quality metric: time to resolve with the reopen rate, changes per week with the share that caused incidents.
• Measure outcomes for users, not only outputs of the team. A green report on response times while users are unhappy is the "watermelon" problem described in Service level management.
• Use metrics to learn, not to blame. If a number is used to punish, people will start managing the number.

The continual improvement register

Improvement ideas come from everywhere: incident reviews, customer complaints, audits, a remark in the coffee corner. A continual improvement register (CIR) is the place where they are recorded, assessed, prioritized and tracked, so that good ideas are not lost and the scarce time for improvement goes to the ideas with the most value. It can be a spreadsheet, a board in the team's work tool or a dedicated module in the IT service management (ITSM) tool; the discipline matters more than the format.

Action items from postmortems often land here too; Postmortems shows how to keep them from quietly expiring.

Plan-do-check-act

Plan-do-check-act (PDCA) is a four-step cycle for learning and improvement: plan a change, do it on a small scale, check the results against what you expected, and act on what you learned by adopting, adjusting or abandoning the change. It is associated with W. Edwards Deming, who built on earlier work by Walter Shewhart; Deming himself later preferred "study" to "check", hence the variant PDSA.

PDCA and the Continual Improvement Model share the same idea: improve in loops, and let measurement decide the next step. The ITIL model is more detailed at the start, because it asks for a vision and a baseline before anyone plans. Many teams use PDCA inside step 5, for each small iteration of a larger improvement.

Who does continual improvement?

Everyone. The service desk agent who rewrites a confusing knowledge article, the engineer who automates a manual check and the manager who removes an approval step that adds no value are all doing continual improvement. Small improvements by many people often add up to more than one large program.

That does not mean nobody is responsible. In ITIL continual improvement appears in two places, and they complement each other:

• As a component of the ITIL Value System, it applies to everything: products, services, practices, the value chain and the way the organization is governed.
• As a management practice, it provides the methods, the register, the reporting and often a few people who coach others and keep the improvements moving.

A healthy sign is a register that is regularly fed by front-line staff, with visible results. If ideas go in and nothing ever comes out, people stop contributing within months.