Most outages are self-inflicted
The background to this process is uncomfortable: a large share of all serious outages are caused not by attacks or hardware failure, but by something someone just changed.
An update rolled out on a Friday. A firewall rule that was meant to be temporary. A certificate nobody knew was expiring.
Change management is not about preventing changes. It is about knowing what is changing, who approved it, and how to get back.
Three types that need different handling
Confusing them is the most common reason the process is experienced as bureaucracy.
Standard changes are pre-approved and low risk: a new user, a routine patch run, a client swap. They should not go via any advisory board. They should be logged and carried out.
Normal changes require assessment: a version upgrade, a new integration, a reconfiguration of something business critical. These are risk-assessed and approved before they are made.
Emergency changes are made to resolve an ongoing disruption. They may jump the queue, but they must be documented afterwards – otherwise the exception becomes the rule within six months.
A useful rule of thumb: if more than a third of your changes are emergencies, it isn't reality that is chaotic, it's the process that is too heavy.
Four things every change should describe
What will be done. Concrete enough that someone else could carry it out.
Which services are affected. This is where a CMDB is needed. Without a register of dependencies, the assessment rests on someone remembering correctly.
How the change is rolled back if it fails. The point most often missing, and the one that costs the most when it is needed.
How you know it succeeded. A verification step, not a feeling that it probably went fine.
A change advisory board that doesn't block
A CAB decides on the normal changes. The board doesn't need to be large or meet often, but it does need a mandate and representation from the business.
A CAB consisting solely of technicians consistently misses the business risk – that the upgrade is technically trivial but is scheduled the same week as month-end close.
Meet often enough not to become a bottleneck, and keep a route for approvals between meetings. A board with a two-week waiting time gets bypassed systematically, and then you lose both control and traceability.
The change calendar
A shared calendar of planned changes does two things.
It prevents two teams changing the same environment at the same time – one of the hardest fault types to troubleshoot afterwards.
And it makes it possible to introduce freeze periods when the business can't tolerate disruption: month-end close, payroll runs, peak season. Saying no in advance is considerably easier than explaining yourself afterwards.
Start lighter than you think
This is the ITIL practice most often built too heavy from the start.
A process that feels like an obstacle gets bypassed, and a bypassed process gives worse traceability than no process at all. Begin by simply registering what changes. Add approvals once you know which changes are actually risky.
The metric
The share of changes that caused an incident. It is the most honest measure of whether the process works, and it should be tracked alongside your other reporting in your ITSM system.
See also incident management for what happens when a change goes wrong, and problem management for how recurring faults are traced to their cause.
