Every IT leader has a war story about a change that went wrong. A routine database patch that took down production for six hours. A firewall rule update that locked out the entire sales team. A "quick" DNS change that cascaded into a full-blown outage across three continents.
IT change management is the discipline that stops these stories from repeating. Yet too many organisations treat it as bureaucratic overhead - a rubber-stamping exercise that slows teams down without adding value. That is a fundamental misunderstanding of what good change management actually does.
Done properly, change management is not about saying no. It is about saying yes with confidence.
Why Change Management Still Matters
The pace of technology change has accelerated dramatically. Cloud-native architectures, continuous deployment pipelines, and agentic AI systems mean that changes happen faster and more frequently than ever before. A mid-sized enterprise might push hundreds of changes per week across its technology estate.
This velocity makes change management more important, not less. When you are deploying ten times a day, the blast radius of a bad change multiplies. Without proper controls, you are not moving fast - you are moving recklessly.
The numbers back this up. Gartner consistently reports that 80% of unplanned downtime is caused by poorly managed changes. That is not a technology problem. It is a process problem.
The Three Tiers of Change
Not all changes are equal, and treating them as such is where most organisations go wrong.
Standard Changes
Pre-approved, low-risk changes that follow a documented procedure. Adding a user to Active Directory. Deploying a tested application update through your CI/CD pipeline. Standard changes should flow through with minimal friction.
Normal Changes
Moderate risk, requiring proper assessment. Migrating a database. Updating firewall rules across production. These need a clear owner, documented impact assessment, tested rollback plan, and appropriate approval.
Emergency Changes
Something is on fire. A critical vulnerability needs patching immediately. These cannot wait for normal approval workflows, but still need documentation after the fact.
Building a Change Advisory Board That Works
Keep it lean (5-7 people), focus on risk not volume, make it asynchronous where possible, and track outcomes.
Change Management in a DevOps World
DevOps shifts change controls left - embedding them into the delivery pipeline. Automated testing, infrastructure as code, feature flags, and canary deployments are all change management controls, just implemented differently.
Practical Framework for IT Leaders
- Classify ruthlessly - use risk matrices based on impact and likelihood
- Automate the boring bits - change request creation, approval routing, conflict detection
- Implement change freezes strategically - not permanently
- Build a change culture - teams need to understand why, not just how
- Review and adapt - your process should itself be subject to continuous improvement
Measuring Success
- Failed change rate - target below 15%
- Emergency change percentage - should be under 10%
- Change lead time - hours for standard, days for normal
- Change-related incident rate - the ultimate measure
Get the basics right. Classify changes proportionally. Automate what you can. Build a culture where change management is seen as an enabler rather than an obstacle.
Read the full article with detailed guidance on CAB structure, DevOps integration, and common anti-patterns at danieljamesglover.com.
Top comments (0)