Change failure rate is one of the most damaging metrics on any IT service desk, yet most organisations treat failed changes as inevitable rather than preventable. This post explains what drives high change failure rates, how ITIL v4 practices help you reduce them, and the practical steps your team can take right now to bring that number down.
What Is Change Failure Rate and Why It Matters
Change failure rate measures the percentage of changes to your IT environment that result in a degraded service, an unplanned outage, or a rollback. It sits alongside deployment frequency, lead time, and mean time to restore as one of the core DORA metrics used to judge the health of IT delivery.
A high change failure rate is expensive in every direction. It consumes incident management capacity, erodes end-user trust, and forces your team into reactive firefighting instead of planned improvement. It also puts SLA commitments at risk and can trigger compliance findings if failed changes touch regulated systems.
Most experts agree that a mature organisation should target a change failure rate below ten percent. Many service desks running without a structured process sit well above that, often because changes are approved informally, tested inconsistently, or deployed without a documented rollback plan.
Understanding the metric is the first step. The second is building a process that addresses the root causes rather than just tracking the number.
The Root Causes of Failed Changes
Failed changes rarely happen because someone made a careless mistake. They happen because the process around the change was weak. The most common root causes fall into a handful of patterns.
- Incomplete impact assessment — the change owner did not identify all the services, configuration items, or dependencies that could be affected
- Inadequate testing — the change was tested in an environment that did not reflect production, or was not tested at all
- Missing rollback plan — when something went wrong, the team had no agreed procedure to restore the previous state quickly
- Poor scheduling — the change was deployed during a high-traffic window or clashed with another change affecting the same infrastructure
- Weak approval governance — standard changes that should have been reviewed as normal or emergency changes were waved through without scrutiny
- Configuration drift — the actual state of the environment did not match what was recorded in the CMDB, so the change was built on bad assumptions
The last point is particularly important. If your CMDB is out of date or incomplete, your change managers are making decisions based on a map that does not match the territory. Automated asset discovery closes that gap by keeping configuration item records current without relying on manual updates.
ITIL v4 Practices That Directly Reduce Change Failure
ITIL v4 does not prescribe a rigid change process, but it gives you a set of practices that, applied together, significantly reduce the likelihood of a failed change.
Change Enablement
Change enablement in ITIL v4 replaces the older "change management" label and shifts the focus from control for its own sake to enabling safe, fast change. It classifies changes into three types.
- Standard changes — pre-approved, low-risk, repeatable changes that follow a documented procedure
- Normal changes — changes that require assessment, approval, and scheduling before implementation
- Emergency changes — urgent changes that need an expedited approval path without bypassing risk assessment
Getting this classification right is critical. Over-classifying changes as standard removes necessary scrutiny. Under-classifying them as emergency creates a habit of bypassing the process under pressure. A well-run change advisory board reviews normal changes with enough lead time to catch problems before deployment, not after.
Problem Management Integration
Many failed changes are repeat failures — the same type of change breaks the same type of service. Problem management exists to find the underlying cause and eliminate it. When your change enablement and problem management practices share data, patterns become visible. A change that has failed three times in six months is not bad luck; it is a problem record waiting to be opened.
Service Configuration Management
Accurate configuration data is the foundation of safe change. Every normal change assessment should include a check of the relevant configuration items in your CMDB to confirm that the recorded state matches reality. If it does not, the change should be paused until the discrepancy is resolved. This is not bureaucracy — it is risk management.
A Practical Checklist to Reduce Change Failure Rate
The following checklist covers the key controls that reduce change failure rate in practice. Work through it for every normal change, and build the relevant items into your standard change templates.
- Define the change scope clearly — what is being changed, on which systems, and at what time
- Identify all affected configuration items using current CMDB data
- Map upstream and downstream service dependencies before assessing risk
- Assign a risk rating using a consistent scoring model, not gut feel
- Require a documented test plan and confirm it was executed in a representative environment
- Require a documented rollback plan with a clear decision trigger — if X happens within Y minutes, roll back
- Schedule the change during an approved maintenance window and check for conflicts with other scheduled changes
- Confirm that the change owner has the skills and access needed to implement and roll back
- Notify affected service owners and end users in advance
- Conduct a post-implementation review for every failed change and a sample of successful ones
- Log all findings in your problem management process to prevent repeat failures
If your team is also working to reduce the volume of emergency changes, the ITSM platform you use should make it easy to see what proportion of changes are being raised as emergency versus normal or standard, and whether that ratio is improving over time.
How to Measure and Track Change Failure Rate Over Time
Measuring change failure rate accurately requires a consistent definition of what counts as a failure. Most teams use one of two definitions: any change that results in an incident, or any change that requires a rollback. Either is valid, but you must apply the definition consistently across all change types and all teams.
The key metrics to track alongside change failure rate include.
- Total changes implemented per period
- Changes resulting in an incident, broken down by change type
- Changes requiring rollback
- Mean time to restore after a failed change
- Percentage of changes implemented as emergency versus normal or standard
- Post-implementation review completion rate
Review these metrics monthly at minimum, and bring them to your CAB or service management review meeting. Trends matter more than absolute numbers. A change failure rate that is falling month over month, even if it has not yet reached your target, is a sign that your process improvements are working.
For teams that want to go deeper on the measurement side, the ITDEVTECH blog covers related metrics including MTTR and first-contact resolution in detail.
Building a Culture That Prevents Failed Changes
Process and tooling can only take you so far. The teams with the lowest change failure rates share a cultural trait: they treat every failed change as a learning opportunity rather than a blame event.
Blameless post-mortems, borrowed from the SRE discipline, are one of the most effective tools for achieving this. When a change fails, the goal of the review is to understand what in the process allowed the failure to happen, not to identify who made the mistake. This distinction matters because it determines whether people are honest in their post-mortems.
A few practical habits that reinforce this culture.
- Celebrate thorough rollback plans, not just successful deployments
- Recognise change owners who raise concerns during CAB rather than staying silent
- Share post-mortem findings across teams so the whole organisation learns from individual failures
- Make it easy to reclassify a change upward in risk if new information emerges before deployment
- Avoid creating pressure to deploy on a fixed date when the risk assessment is not complete
The organisations that manage change well are not the ones that never fail — they are the ones that fail less often over time, recover quickly when they do, and learn from every failure systematically.
Frequently Asked Questions
What is a good change failure rate target for an IT service desk?
Most ITSM practitioners consider a change failure rate below ten percent to be a reasonable target for a maturing organisation. High-performing teams often achieve rates below five percent. The right target for your organisation depends on your current baseline, your risk appetite, and the complexity of your environment. Start by measuring accurately, then set an improvement target from your actual baseline.
How does a CMDB help reduce failed changes?
A CMDB gives change managers accurate, current information about the configuration items affected by a change and their dependencies. When that data is stale or incomplete, impact assessments miss affected services, and changes are deployed into environments that do not match expectations. Automated asset discovery tools keep CMDB records current, reducing the risk of changes built on bad assumptions.
What is the difference between a failed change and an emergency change?
A failed change is one that results in a service degradation, unplanned outage, or rollback after implementation. An emergency change is one that is raised and approved urgently to address a critical situation, such as a security patch or a fix for a major incident. Emergency changes are not inherently failures, but they carry higher failure risk because they bypass some normal assessment steps.
Who is responsible for reducing change failure rate?
Ownership typically sits with the change manager or change enablement practice owner, but reducing change failure rate is a shared responsibility. Change owners must submit complete and accurate change records. The CAB must apply consistent scrutiny. Problem management must close the loop on repeat failures. Leadership must create a culture where raising concerns is encouraged.
How often should post-implementation reviews be conducted?
Post-implementation reviews should be conducted for every failed change without exception. For successful changes, most teams review a representative sample — typically all high-risk changes and a random selection of medium-risk ones. The findings should feed directly into your problem management process and into updates to your standard change templates.
Can automation help reduce change failure rate?
Yes, in several ways. Automated deployment pipelines reduce human error during implementation. Automated testing in pre-production environments catches issues before they reach production. Automated CMDB discovery keeps configuration data accurate. Automated scheduling tools flag conflicts between concurrent changes. Automation does not replace good process, but it removes several of the manual steps where errors most commonly occur.
