How do you make sure an IT service never gets worse, but actually gets better over time? That is the problem Continual Improvement solves: it gives you a method to stop fires before they start, and to slowly tweak services so they become faster, cheaper, and more reliable, without needing a massive, risky overhaul every few years.
Jump to a section
A simple way to picture Continual Improvement
A house is never truly finished. Even after the last coat of paint dries on a new kitchen, the roof will inevitably spring a leak, the boiler will start making a worrying noise, or a new smart-home technology will render the current setup outdated. A smart homeowner knows this. They do not just fix the leak and move on. They ask: why did the roof fail? Was it poor materials, a bad installation, or just age? They then plan a small improvement: replace worn shingles now, schedule the next inspection in six months, and research a more durable material for the future.
This is the heart of Continual Improvement. It is not about a single heroic fix, like a plumber arriving to stop a flood. It is the ongoing, disciplined cycle of checking what is working, identifying what could be better, making a small change, and then checking again. In IT, this replaces the old habit of building a service, launching it, and hoping for the best. The house (the IT service) is always being inspected, tweaked, and upgraded, not because it is broken, but because the owner (the business) wants it to be safer, cheaper, and more comfortable over time.
The homeowner has a model: assess the current state of the house, decide where to improve, make a small change, check the result, and repeat. That cyclic process is the Continual Improvement Model, and it keeps the house, or the IT service, from falling into disrepair while adapting to new needs.
Continual Improvement is a core component of the ITIL 4 framework. Think of it as the engine that drives a service forward. It is not a one-off project or a reaction to a disaster. It is a repeating, planned cycle of activity that aims to align IT services with the ever-changing needs of the business.
The model itself is often presented as a seven-step process. ITIL 4 does not mandate a specific number of steps, but the most common and exam-relevant version is this:
What is the vision? This is the starting point. You must understand the overall business goals. If the business wants to reduce customer waiting time by 20%, the IT improvement must support that, not just make the server run faster.
Where are we now? This is a realistic assessment of the current state. You measure current performance. If the current customer waiting time is 10 minutes, you know you are 10 minutes away from the goal.
Where do we want to be? This sets a clear, measurable target. For example: reduce customer waiting time from 10 minutes to 8 minutes within three months.
How do we get there? This is the plan. You decide on specific actions. Perhaps you will upgrade a database, or add a new server, or train staff on a new tool.
Take action. This is where you execute the plan. You make the change.
Did we get there? After the change, you measure again. Is the waiting time now 8 minutes? If yes, great. If not, you go back to the plan and adjust.
How do we keep the momentum? The final step ensures that the improvement is sustained and that the cycle does not stop. You embed the change into standard operating procedures.
This model replaces the old approach of 'firefighting', where IT teams only react to problems. It is proactive. It also replaces the 'big bang' approach, where a massive change is made all at once, often causing disruption. Continual Improvement is about many small, safe, iterative improvements.
A key term here is 'iteration'. This means repeating the cycle. Each time you go through the steps, you should get a little closer to the ideal. You are not looking for perfection in one go. You are looking for steady, constant progress.
Another important concept is the 'Plan-Do-Check-Act' (PDCA) cycle, also known as the Deming Cycle. ITIL 4's Continual Improvement model is essentially a more detailed version of PDCA. Plan corresponds to 'how do we get there'. Do is 'take action'. Check is 'did we get there'. Act is 'keep the momentum'.
The model is applied at all levels of the organisation. A help desk team might use it to reduce ticket resolution time. A data centre team might use it to improve server uptime. A finance team might use it to reduce IT costs. The key is that the starting point is always the business vision, not a technical whim. You improve things that matter to the business.
Do not confuse Continual Improvement with Change Management. Change Management is about controlling a single change to avoid risk. Continual Improvement is the broader cycle that generates those changes. The Improvement model identifies a needed change, and then the change goes through the formal change management process. They work together.
Finally, remember that Continual Improvement requires a culture of learning. People must feel safe to report problems and suggest improvements. If staff are punished for pointing out flaws, the model will fail. It needs trust and honest measurement.
What is the vision?
Identify the overarching business goal or strategy. This ensures that any improvement you make directly supports what the organisation is trying to achieve.
Where are we now?
Perform a baseline assessment. Measure current performance, identify gaps, and understand the current state of the service or process. This provides a starting point for improvement.
Where do we want to be?
Define a clear, measurable target that is aligned with the vision. This gives the team a concrete goal to aim for and a way to know when they have succeeded.
How do we get there?
Create a detailed plan. Identify the specific actions, resources, and timeline required to close the gap between the current state and the target state.
Take action.
Execute the plan. Implement the agreed changes in a controlled manner, ideally using small, iterative steps to minimise risk.
Did we get there?
Measure and evaluate the outcome after the action has been taken. Compare the new metrics against the target to determine if the improvement was successful.
How do we keep the momentum?
Standardise the successful changes into normal operations, document lessons learned, and ensure the cycle continues by identifying the next improvement opportunity.
Let us look at a real-world scenario. Sarah is an IT manager at a mid-sized online retailer. The sales team complains that the website is slow during peak hours, causing customers to abandon their shopping carts. Sarah uses the Continual Improvement model to solve this.
First, she clarifies the vision. The business goal is to increase sales by 5% this quarter. A slow website is killing sales. The improvement must directly support that business goal.
Second, she measures where they are now. She uses tools to monitor the website's load time. She finds the average page load time on a busy Saturday evening is 4.5 seconds. This is the baseline.
Third, she defines where they want to be. The team agrees: a target of 2 seconds page load time during peak hours is acceptable. This is the goal.
Fourth, she plans how to get there. The team brainstorms options. They list several potential actions:
Upgrade the server hardware.
Optimise the website code (compress images, remove unused scripts).
Implement a content delivery network (CDN) to cache content closer to users.
Increase the database query speed by indexing.
They choose to start with the CDN because it is a lower-risk, high-impact change that can be implemented quickly.
Fifth, they take action. The team deploys the CDN configuration. This is done outside peak hours to minimise risk.
Sixth, they check if they got there. They monitor the same peak Saturday evening. The new average load time is 2.1 seconds. Success. The target is met.
Seventh, they keep the momentum. They document the new CDN configuration as standard. They also set up a monthly review to check the load time and see if any other improvements are needed. The cycle is now continuous.
What did Sarah actually do? She did not just fix the symptom (slow website) with a random solution. She used a structured model to align the improvement with a business goal (sales), measure the impact, and then systematically implement a solution. The next month, the review might show that server CPU usage is now a bottleneck, so she feeds that back into the model and starts a new improvement cycle.
This iterative, data-driven approach means the IT team is no longer guessing. They are making informed, small improvements that directly support the business. This is the practical application of Continual Improvement.
The ITIL 4 Foundation exam will test your understanding of the Continual Improvement model's purpose, structure, and relationship to other concepts. Here is what you need to know.
The exam focuses heavily on the model's connection to the overall Service Value System (SVS). The Continual Improvement model is not a standalone process; it is the engine that drives the entire SVS. Expect questions that ask: 'What is the starting point of the Continual Improvement model?' The answer is always 'the vision' or 'the business vision'. Not 'the problem' or 'the technology'. - You will be asked to identify the correct order of the steps. A common trap is to misplace the 'measurement' steps. Remember: you measure 'where you are now' BEFORE you plan 'how to get there'. You measure again AFTER you take action to see if you succeeded. The exam loves to test this sequence. - Another key area is the relationship between Continual Improvement and the ITIL guiding principles. The principle 'Focus on value' is directly linked: every improvement must be justified by the value it brings to stakeholders. The principle 'Progress iteratively with feedback' is essentially the Continual Improvement model in action. Expect matching questions. - The exam will test the difference between Continual Improvement and a 'project'. An improvement is ongoing and iterative, while a project has a defined start and end date. A project can be part of an improvement cycle, but the cycle itself is never-ending. - You must know the difference between 'Continual Improvement' and 'Change Control' (previously called Change Management). Change Control is a specific practice that authorises and controls individual changes. Continual Improvement identifies and prioritises the changes that need to be made. - Watch out for 'waterfall' thinking. The exam will not use that word, but it will test if you understand that improvements are small and iterative, not large and infrequent. Any answer that suggests a big, one-time fix is wrong. - Definition to memorise: 'Continual Improvement is a recurring activity to align IT services with the changing needs of the business by identifying and implementing improvements.' The exam may ask for a definition or ask you to identify which activity is not part of Continual Improvement. - The model is applicable at ALL levels: strategic, tactical, and operational. A question might say: 'At what level of the organisation is the Continual Improvement model applied?' The answer is 'at all levels'. - Finally, know that the model uses metrics to measure success. These metrics must be tied to the vision. An exam question might present a metric (e.g., server uptime 99.9%) and ask if it is a good metric for an improvement that aims to reduce customer complaints. The answer is no, because it is not directly linked to the business goal (reducing complaints).
To prepare, practise putting the seven steps in order and matching them to the PDCA cycle. Also, practice identifying which step a given description belongs to. For example, 'We analysed the current server logs' belongs to 'Where are we now?'.
The Continual Improvement model always starts with understanding the business vision, not a technical problem.
The model consists of a repeating cycle: assess current state, define target, plan, act, measure, and standardise.
Continual Improvement is a recurring activity, not a one-off project; it is the engine of the Service Value System.
Each improvement must be measured against a clear, business-aligned metric to confirm success.
The model applies at all levels of the organisation, from strategic planning to daily operational tasks.
A culture of trust and learning is essential; staff must feel safe to identify and report improvement opportunities.
These come up on the exam all the time. Here's how to tell them apart.
Continual Improvement
An ongoing, repeating cycle with no defined end date.
Focuses on iterative, small improvements over time.
Drives the organisation towards a long-term vision.
Project Management
A temporary endeavour with a defined start and end date.
Focuses on delivering a specific output or outcome once.
Aims to complete a scope within budget and time constraints.
Continual Improvement Model
ITIL-specific, with seven named steps.
Explicitly starts with the 'vision' as the first step.
Includes a step to 'keep the momentum' to ensure sustainability.
Plan-Do-Check-Act (PDCA)
Generic quality management cycle with four steps.
Often starts with 'Plan' without requiring a business vision context.
Ends with 'Act', which implies standardisation but is less detailed.
Continual Improvement
Identifies and prioritises what needs to change.
Focuses on the 'why' and the 'what' of improvements.
Feeds into Change Control by generating Requests for Change (RFCs).
Change Control
Authorises and manages the implementation of individual changes.
Focuses on the 'how' and the 'risk' of a single change.
Receives RFCs from Continual Improvement and other sources.
Mistake
Continual Improvement is only about fixing things that are broken.
Correct
It is about proactively making services better, even if they are currently working, to align with evolving business needs.
People naturally associate 'improvement' with 'remediation'. The model is proactive, not reactive.
Mistake
The Continual Improvement model is a rigid, mandatory step-by-step procedure that must always be followed in exact order.
Correct
It is a flexible framework. The steps can be adapted, and you can revisit earlier steps if new information emerges.
The ITIL model is often taught as a list, leading learners to assume it must be followed like a recipe. The exam treats it as guidance.
Mistake
Once an improvement is made and the target is met, the job is done and the model is no longer needed for that service.
Correct
The model is a continuous cycle. After meeting the target, you must 'keep the momentum' and start looking for the next improvement.
The word 'continual' itself means ongoing, but beginners often think of it as a single project with a finish line.
Mistake
The Continual Improvement model applies only to the IT operations team.
Correct
It applies to everyone, from strategy to operations, and to all IT practices and services.
Learners compartmentalise IT into 'operations' and 'projects'. The model is universal across all ITIL practices.
Mistake
To start the model, you need a clear problem or complaint from users.
Correct
You can start the model proactively based on a business opportunity, a change in strategy, or a desire to innovate, not just react to problems.
Most people associate improvement with problem-solving. The model also drives innovation and proactive alignment.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Problem Management finds and fixes the root cause of incidents. Continual Improvement is a broader, proactive cycle that can address problems, but also looks for opportunities to improve performance, reduce costs, or align with new business goals.
The model is a guide, not a strict rule. You can adapt the steps to the situation, but for simple improvements you might skip some formal steps. For complex changes, following the full cycle is wise.
A project has a defined start and end date and produces a specific output. Continual Improvement is an ongoing, never-ending cycle. A project can be a part of an improvement initiative, but the cycle continues after the project ends.
ITIL's model is a more detailed version of PDCA. Plan corresponds to 'How do we get there', Do is 'Take action', Check is 'Did we get there', and Act is 'How do we keep the momentum'.
Yes. While it is part of the ITIL framework, the model is generic enough to be used in HR, finance, or any business function. ITIL 4 encourages this enterprise-wide view.
Starting with a technical solution without first understanding the business vision. For example, deploying new software because it is 'faster', when the real business need is to reduce customer churn, not just speed.
You've finished Continual Improvement. Continue through the ITIL4F study guide to build a complete picture of the exam.
Done with this chapter?