The continual improvement practice

ITIL-140 studied the practices that keep services running from hour to hour: the service desk, incident, problem, service request, change, and monitoring and event management. This course studies the practices that shape what is delivered, how it is agreed, how it is put into production and how it gets better over time. It covers continual improvement, service level management, service configuration management, IT asset management, release management, deployment management, relationship management, supplier management and, at Foundation level, information security management. Together with ITIL-140, it completes the set of practices the ITIL 4 Foundation exam expects you to know.

The course begins with continual improvement because every other practice depends on it. A service level that is never reviewed, a configuration database that is never audited or a supplier contract that is never renegotiated slowly drifts away from what the organization needs. Continual improvement is the practice that stops that drift.

As in the earlier ITIL courses, HSM University is independent. ITIL® is a registered trademark of PeopleCert. All scenarios and questions are original, and the course does not reproduce official text or exam questions.

A running example: Larchmont Logistics

Throughout this course you will follow Larchmont Logistics, an invented freight and warehousing company headquartered in Winnipeg with 2,400 staff, eleven distribution centres across the Prairies and Ontario, and an internal IT group called Larchmont Technology Services (LTS). LTS runs a warehouse management system, a transport planning platform, a customer shipment portal, email and collaboration tools, and a mix of on-premises servers and cloud services. It relies on a cloud provider, a network carrier, a managed security service and several software vendors. Each lesson uses Larchmont to show how a practice works in a realistic setting. All figures for Larchmont are invented for teaching.

Purpose of the continual improvement practice

In plain words, the purpose of the continual improvement practice is to align the organization's practices and services with changing business needs through the ongoing improvement of products, services, practices and any element involved in managing them. Three ideas are worth drawing out. Improvement is ongoing, not a project that finishes. It covers everything, from a single knowledge article to the whole service value system. And its reference point is changing business needs: improvement that makes IT more elegant without helping anyone achieve an outcome is not improvement in the ITIL sense.

Continual improvement appears in ITIL 4 in three places, which can confuse newcomers. It is one of the components of the service value system, an activity in the service value chain (improve), and a general management practice. ITIL-120 introduced the continual improvement model and ITIL-130 described the improve activity. This lesson looks at the practice: the resources, roles, methods and information an organization needs so that improvement actually happens, again and again, across every practice.

The continual improvement model, briefly

ITIL-120 worked through the continual improvement model in detail, so a short recap is enough here. The model asks seven questions in order: What is the vision? Where are we now? Where do we want to be? How do we get there? Take action. Did we get there? How do we keep the momentum going? The first step links the improvement to the organization's direction. The second sets an honest baseline, measured rather than assumed. The third defines measurable targets. The fourth chooses an approach, often a series of small iterations rather than one big change. The fifth carries it out. The sixth checks the results against the targets. The seventh embeds the change so that people do not drift back to old habits, and celebrates success to build appetite for the next improvement.

The model is a thinking aid, not a bureaucratic sequence. Small improvements may move through all seven steps in an afternoon. Large ones may loop through "take action" and "did we get there" many times. What matters is that the questions are asked: improvements that skip the baseline cannot prove they helped, and improvements that skip momentum often fade.

What the practice needs: the four dimensions

Like every practice, continual improvement is described through the four dimensions. Under organizations and people, it needs leaders who sponsor improvement, a culture where people can raise problems without blame, time set aside for improvement work, and skills in analysis, facilitation and change. Under information and technology, it needs a place to record improvement ideas, measurement data from other practices and tools for analysis. Under partners and suppliers, it needs suppliers who take part in improvement and contracts that reward it. Under value streams and processes, it needs a light, repeatable way of capturing, assessing, prioritizing, approving and tracking improvements.

Roles and responsibilities

ITIL is clear that continual improvement is everyone's responsibility. An agent who rewrites a confusing knowledge article, a developer who removes a manual step from a pipeline and a supplier manager who renegotiates a weak service credit are all doing continual improvement. Still, someone must own the practice itself, or nobody makes sure the register is maintained, the data is trustworthy and lessons are shared.

Many organizations appoint a continual improvement lead or a small improvement team. Their job is not to do all the improving but to enable it: to coach teams in methods, maintain the register, make measurement available, connect related ideas from different teams and report progress to leadership. In larger organizations, practice owners for each practice also own improvements to their practice. Leadership has a distinctive role: setting direction, funding improvement, protecting improvement time when operational pressure rises and modelling the behaviour they want to see.

The continual improvement register

The continual improvement register (CIR) is a database or structured document that tracks improvement ideas from capture to completion. ITIL-120 introduced it; here we look at how to run one well. An organization may have one register or several, for example one per team plus a shared register for cross-team ideas. What matters is that ideas are captured, not lost; that each idea has enough information to be assessed; that priorities are visible; and that completed improvements are reviewed for benefits.

A useful register entry records the idea and its source, the problem or opportunity it addresses, the expected benefit and how it will be measured, a rough estimate of effort and cost, the owner, the status and, once complete, the measured result. Sources include incident and problem trends, service reviews with customers, audits, staff suggestions, supplier proposals, user feedback, post-incident reviews and benchmarking.

Prioritizing improvements

There are always more improvement ideas than capacity. Prioritization decides which ideas move forward. Simple organizations use a value and effort matrix: high-value, low-effort ideas ("quick wins") go first, high-value, high-effort ideas are planned as larger initiatives, low-value, low-effort ideas are done when convenient and low-value, high-effort ideas are dropped. ITIL-130 introduced weighted shortest job first (WSJF), which divides the cost of delay by the size of the job, so that work with high value relative to its size goes first.

The cost of delay in WSJF is often estimated as the sum of three relative scores: user or business value, time criticality, and risk reduction or opportunity enablement. Each is scored on a relative scale such as 1, 2, 3, 5, 8, 13, and the job size is scored the same way. The scores are judgments, not measurements, so the method works best when a small group scores ideas together and discusses disagreements.

# Rank continual improvement register entries by WSJF and by value/effort quadrant
ideas = [
    # name, value, time criticality, risk reduction, size
    ("Automate printer resets", 5, 3, 2, 2),
    ("Self-service portal", 13, 5, 3, 13),
    ("Retire old file server", 3, 8, 8, 5),
    ("Rewrite onboarding checklist", 5, 2, 1, 1),
    ("Supplier scorecard dashboard", 8, 3, 5, 5),
    ("Rebuild CMDB discovery", 8, 5, 8, 8),
]
rows = []
for name, v, t, r, size in ideas:
    cod = v + t + r
    wsjf = cod / size
    quadrant = ("quick win" if cod >= 10 and size <= 3 else
                "major initiative" if cod >= 10 else
                "fill-in" if size <= 3 else "reconsider")
    rows.append((wsjf, name, cod, size, quadrant))
rows.sort(reverse=True)
print(f"{'rank':<5}{'idea':<30}{'CoD':>4}{'size':>6}{'WSJF':>7}  quadrant")
for i, (w, name, cod, size, q) in enumerate(rows, 1):
    print(f"{i:<5}{name:<30}{cod:>4}{size:>6}{w:>7.2f}  {q}")

rank idea                           CoD  size   WSJF  quadrant
1    Rewrite onboarding checklist     8     1   8.00  fill-in
2    Automate printer resets         10     2   5.00  quick win
3    Retire old file server          19     5   3.80  major initiative
4    Supplier scorecard dashboard    16     5   3.20  major initiative
5    Rebuild CMDB discovery          21     8   2.62  major initiative
6    Self-service portal             21    13   1.62  major initiative

The scores drive the order, but the conversation matters as much as the arithmetic. If the team disagrees strongly about the value of the self-service portal, that disagreement is useful information: perhaps the portal's value depends on which users it targets, and a smaller first release aimed at the warehouse staff who log the most requests would score better.

Improvement methods

ITIL does not prescribe a single improvement method. It encourages organizations to choose a small number of methods that suit their culture and to use them consistently. Common choices include Lean, which focuses on removing waste and improving flow; Agile, which delivers improvement in short iterations with frequent feedback; DevOps, which applies automation and shared responsibility to the path from code to production; the Plan-Do-Check-Act (PDCA) cycle associated with Deming; Six Sigma, which uses statistical methods to reduce variation; and simple techniques such as kaizen events, A3 problem solving and retrospectives.

Having too many methods causes confusion: teams spend time arguing about the method instead of improving. Having none causes inconsistency: every team invents its own approach, and lessons cannot be shared. A common middle path is to adopt the continual improvement model as the overall frame, use PDCA or retrospectives for small improvements, use Lean value stream mapping (covered in ITIL-130) for flow problems and reserve heavier methods for problems that need them.

Embedding improvement in every practice

Continual improvement works best when it is built into the other practices rather than run as a separate programme. Each practice has natural improvement triggers. Incident management feeds post-incident reviews. Problem management turns recurring incidents into fixes. Service level management holds service reviews that surface gaps. Change enablement reviews failed changes. Supplier management reviews supplier performance. Monitoring reveals trends before they cause incidents. When these triggers routinely produce register entries, improvement becomes part of normal work.

A practical test is to ask where the last ten register entries came from. If most came from a single annual survey, improvement is not embedded. If they came from a mix of reviews, trends, staff ideas and customer conversations, it probably is.

Measuring improvement itself

An improvement practice should measure its own effectiveness. Useful measures include the number of ideas captured and the share that come from front-line staff; the time from capture to decision; the share of approved improvements completed; the share of completed improvements whose benefits were measured; and the realized benefits, such as hours saved, incidents avoided or satisfaction gained. A register full of ideas that never move is a warning sign: people stop contributing when nothing happens.

Maturity assessments and benchmarks

Organizations sometimes assess the maturity of their practices to decide where improvement is most needed. ITIL 4 includes a maturity model, and PeopleCert offers formal assessments, but many organizations run simpler self-assessments: for each practice, they score how well defined, measured and improved it is on a scale of one to five, then compare scores with the importance of the practice to their services. A low score on an important practice is a strong candidate for improvement. A high score on an unimportant practice may indicate over-investment.

Benchmarks compare an organization with others, for example cost per ticket or change success rate. They are useful for spotting large gaps but can mislead when organizations measure differently. A benchmark should prompt questions, not settle arguments.

Culture: the hardest part

Methods and registers are the easy part. The hard part is culture. Improvement requires people to admit that something could be better, which can feel risky. If raising a problem leads to blame, people hide problems. If improvement ideas disappear into a register that nobody reads, people stop offering them. If managers always sacrifice improvement time when the queue grows, people learn that improvement is optional.

Leaders build an improvement culture by responding to bad news with curiosity, giving credit to people who raise problems, reporting back on what happened to suggestions, protecting a share of capacity for improvement and sharing successes widely. The guiding principles from ITIL-120 apply directly: progress iteratively with feedback, start where you are, keep it simple and practical, and collaborate and promote visibility.

ITIL (Version 5) note

Published summaries of ITIL (Version 5), checked in October 2026, list continual improvement as a general management practice, as in ITIL 4. Its purpose is described in similar terms. As ITIL-140 explained, Version 5 summaries describe 34 practices in two groups, product and service management and general management. Always check the current official materials for exact wording.