Ask any IT director who's been through an ITIL implementation how it went, and you'll hear a similar story: "We got the incident process working, change management is humming along, the service desk has SLAs. Then... not much happened after that." The architecture is sound. The processes exist. But the organization isn't getting better.
This is the Continual Improvement gap. It's the single most common failure mode in ITSM implementations — not because the concept is unclear, but because the operating model for improvement is almost never built alongside the processes it's supposed to improve.
Continual Improvement is one of the 34 ITIL 4 practices. Its purpose: "to align the organization's practices and services with changing business needs through the ongoing identification and improvement of services, service components, practices, or any element involved in the efficient and effective management of products and services." Source: AXELOS, ITIL 4 Foundation, 2019.
Why Continual Improvement Stalls (The Real Reasons)
The improvement methodology isn't the problem. PDCA (Plan-Do-Check-Act), the 7-Step Improvement Model, the CI register — these are well-understood frameworks. The stall happens for organizational, not methodological, reasons:
- No one owns it. Continual improvement is everyone's responsibility, which means it defaults to being no one's. Without a named owner — an Improvement Champion, a Process Manager, a CI Lead — the practice doesn't happen consistently.
- No dedicated time. Improvement requires slack in the system. Organizations running at 100% utilization — all reactive, all the time — can't improve because there's no capacity to do anything other than respond to the queue.
- The register is a graveyard. A CI register where items go in and never come out (because there's no prioritization, no resourcing, no review cadence) is worse than no register — it demoralizes the team and creates cynicism about the process.
- Metrics without meaning. Tracking 47 metrics because the platform makes it easy, but having no consensus on which two or three actually tell you if things are getting better, creates noise without signal.
The PDCA Cycle: More Than a Diagram
Most IT professionals have seen the PDCA wheel. Fewer have actually operationalized it as a structured quarterly rhythm. Here's what each phase looks like in practice for an ITSM team:
PLAN
Identify what to improve. Review your CI register, service performance data, user feedback, and incident patterns. Define a specific, measurable improvement goal with a target date and success metric. Scope it to what can be completed in 90 days.
DO
Execute the improvement initiative. This might be a process change, a knowledge base build-out, a training program, or a tool configuration. Document what was done and what was expected. Keep it small enough to finish.
CHECK
Measure the outcome against your baseline. Did the metric move? By how much? What unexpected effects occurred? This phase requires data you collected before starting — if you didn't measure baseline, you can't check results.
ACT
Standardize what worked. Roll back or adjust what didn't. Feed the learning back into the register and the next planning cycle. The Act phase is what turns a one-time fix into a permanent capability — it's the most skipped step in most organizations.
The 7-Step Improvement Model in Plain English
The ITIL 7-Step Improvement Model (introduced in ITIL v3, refined in ITIL 4) gives you a systematic approach to identifying, defining, gathering, and acting on improvement opportunities. Here's how to use it without the certification jargon:
Define What You Should Measure
Start with the business outcome, not the available metric. What does "better" look like for your stakeholders? Work backwards from the outcome to the indicator.
Define What You Can Measure
Now check reality. Of the metrics you'd ideally track, which are actually available in your platform? This step surfaces the instrumentation gaps you need to close.
Gather the Data
Establish your baseline. Run the reports. Export the data. Take a snapshot before you change anything. This is the step most organizations skip — and why they can't prove improvement later.
Process the Data
Turn raw data into information. Filter out noise. Identify the meaningful patterns. This is where visualization earns its keep — a well-designed dashboard communicates faster than a spreadsheet.
Analyze the Information
Ask why. What's driving the pattern you see? What's the root cause? This is where improvement planning earns its rigor — and where rushing leads to treating symptoms instead of causes.
Present and Use the Information
Communicate findings to the right audience in language that lands with them. Executives want cost and risk impact. Agents want workload and quality impact. Tailor the presentation accordingly.
Implement the Improvement
Execute the change via your Change Enablement practice. Track implementation. Measure post-implementation. Close the loop back to Step 1 with the new baseline.
Building a CI Register That Actually Gets Used
The CI register is the central artifact of continual improvement — a living backlog of improvement opportunities, prioritized, owned, and tracked. The difference between a CI register that drives real change and one that becomes a graveyard is the operating model around it.
A functional CI register entry has:
- A clear description of the opportunity (specific, not vague)
- A business impact statement — what does improving this unlock for the organization?
- An owner — one person, not "the team"
- A priority score — impact × effort is a reasonable starting framework
- A target completion date — without this, it's a wishlist item
- A success metric — how will you know it worked?
Here's a sample entry format:
| Opportunity | Business Impact | Owner | Priority | Target Date | Success Metric |
|---|---|---|---|---|---|
| Reduce password reset ticket volume | Frees ~4 agent-hours/week for complex work | Service Desk Lead | HIGH | Q2 2026 | <10 password tickets/week |
| Improve first-contact resolution rate | Reduces repeat contacts, improves CSAT | IT Manager | HIGH | Q3 2026 | FCR from 58% → 72% |
| Reduce change failure rate | Reduces emergency changes, on-call strain | Change Manager | MED | Q3 2026 | CFR from 12% → <5% |
| Build SLA reporting dashboard | Executive visibility into IT performance | IT Director | MED | Q2 2026 | Monthly report to leadership |
| Document 20 top KB articles | Enables self-service deflection | Knowledge Manager | STD | Q4 2026 | 20 articles published, 15% deflection |
"Continual improvement isn't an ITIL practice. It's an organizational muscle. Like any muscle, it atrophies without consistent use — and it takes intentional training to build."
The Operating Rhythm That Works
The most successful ITSM organizations I've seen build improvement into their operating cadence — not as a separate initiative, but as a recurring ritual:
Weekly: Service desk lead reviews top 5 recurring ticket categories. Flags any patterns for the CI register. Takes 15 minutes.
Monthly: IT Manager reviews service performance metrics vs. targets. Reviews open CI items. Adjusts priorities based on current context. 30-minute review meeting.
Quarterly: IT Director presents service performance to business leadership. Reviews completed improvements and their measured impact. Plans next quarter's improvement focus. This is the meeting that justifies the IT budget.
Annually: Full service portfolio review. Assess strategic alignment of current service catalog with business direction. Major priority resets.
Where AI Accelerates Continual Improvement
AI doesn't replace the improvement cycle — but it can make the inputs richer and the analysis faster. The most practical AI applications in CI are performance trend analysis (AI flags metric degradation before it becomes visible in manual review) and improvement opportunity identification (AI surfaces patterns in ticket data that suggest process gaps). Both are available in mature ITSM platforms today. The precondition is a working improvement cycle that can consume and act on those inputs. Build the cycle first. Then add AI acceleration.
• AXELOS — ITIL 4 Foundation, 2019
• AXELOS — ITIL 4 Create, Deliver and Support (CDS), 2020
• Deming Institute — The PDSA Cycle (Plan-Do-Study-Act)
• HDI — State of the Service Desk, 2024
• ISO/IEC 20000-1:2018 — Continual Improvement Requirements
• Lean IT Association — Value Stream and CI Practice Standards
Ryan Holzer is an ITIL Expert and Founder & Principal ITSM Consultant at Tideline Insights, serving IT leaders across the U.S. Founder, Florida ITSM Meetup Series.