Jun 26 / Aray Kaken

Transformation Model vs Continual Improvement Model: When to Use Which

ITIL Version 5 gives you two models for making things better, and the difference between them comes down to one question. Are you improving within your ITIL Value System, or transforming the value system itself? The Continual Improvement Model (CIM) is for the first. The Transformation Model is for the second. Pick the wrong one and you either over-engineer a small fix or under-power a major change.

The core distinction

The Continual Improvement Model is a high-level, repeatable guide for ongoing betterment. It works through familiar questions, such as what is the vision, where are we now, where do we want to be, how do we get there, did we get there, and how do we keep the momentum. It applies at any level of complexity as long as you adjust the steps to fit. It is the right tool when you are improving how the existing system performs.
ITIL Transformation Model: Big Picture
Fig. 2.3. ITIL Continual Improvement Model, PeopleCert

The Transformation Model, by contrast, is built for changing the system itself: the operating model, the structure, the relationships, and the way value is created. It brings the heavier machinery, with four layers (governance, positioning, execution, learning), twelve stages, twenty-four steps, and context-specific execution patterns, because system-level change carries more uncertainty, more stakeholders, and more ways to fail. We cover that structure in detail in our guide to the ITIL Transformation Model.
ITIL Transformation Model: Big Picture
Fig. 3.3. ITIL Transformation Model, Twenty Four Steps, PeopleCert

A simple way to decide

ITIL Transformation Model: Big Picture
Fig. 2.4. ITIL Transformation vs ITIL Continual Improvement Model, PeopleCert
Question Lean towards CIM Lean towards the Transformation Model
What is changing? Performance within the current system The system itself
Is the target state clear? Often yes, or discoverable with light experimentation Frequently still forming
Scale and stakes  Incremental, contained Strategic, cross-cutting
Number of stakeholders Few to moderate Many, across functions
Governance needed Lightweight Deliberate, multi-level
Typical example Reducing incident resolution time Re-platforming and reorganising service delivery

Why not just use one model for everything?

Because the cost of mismatch runs both ways. Run a routine improvement through the full Transformation Model and you smother a quick win in governance overhead. Run a genuine system-level transformation through the Continual Improvement Model and you skip the positioning and governance work that keeps large change coherent, which is precisely where big programmes tend to fragment.

There is also a subtler point. The Transformation Model already contains continual-improvement thinking inside it. Its Execution layer's Implement pattern (Appraise, Plan, Do, Study, Act) is an improvement cycle in everything but name, and its Learning layer is built to feed lessons back continuously. So the two models are not rivals. The smaller one is, in effect, woven into the larger.

How to choose in practice

Start with the question of scope. If you are making the current value system work better, reach for the Continual Improvement Model and scale the rigour to the size of the change. If you are changing what the value system is, reach for the Transformation Model and use its positioning layer to decide how much of the machinery each part of the work actually needs. The same transformation can even use both: the model for the overall reshape, and lighter improvement cycles for the contained pieces inside it.

Both models, and how they fit together, are taught in full in our ITIL Transformation Version 5 certification course.

 👉 Check out our ITIL Transformation Version 5 Certification page below
Created with