Change Management Failures That Never Look Like Failures

Ask most IT teams whether they have change management and the answer is an immediate yes. There is a policy. There is a ticketing tool. There is a change advisory board that meets every week. On paper, every change is requested, assessed, approved, tested and reviewed.

Then something breaks in production on a Thursday night, and the investigation finds a change that nobody remembers approving, made by someone who also tested it, released it and closed the ticket. Nothing in the process failed loudly. It simply stopped doing its job, one reasonable shortcut at a time.

That is the problem with change management. Its failures rarely look like failures. Every record a reviewer asks for exists, and every metric looks healthy. You only see the gap when you read the evidence closely.

Five quiet failures

1. The emergency that became normal

Every process needs an emergency route for genuine outages. The warning sign is volume. When emergency changes make up a large share of all changes, they are no longer emergencies. They are the fast lane that skips assessment and testing because the normal lane is too slow. Look at the trend month by month, and at who raises them. A handful of people using the emergency route as habit tells you more than any policy.

2. Approving your own work

Segregation of duties is the heart of change control: the person who builds a change should not be the one who approves it and moves it to production. In practice, small teams, shared administrator accounts and tool permissions that were never tightened let one person do it all. The ticket shows an approval, but the approver and the implementer are the same name, or a generic account nobody owns.

3. Approval after the fact

Compare the approval timestamp with the time the change was actually deployed. A surprising number of approvals arrive hours or days after the change went live. The record looks complete at month end, but the approval controlled nothing. It documented a decision already made.

An approval that arrives after deployment controls nothing. It only documents.

4. Changes that never entered the process

The most important changes are often the ones with no ticket at all: a firewall rule added during an incident, a configuration tweak made directly in the cloud console, a vendor patching a system through remote access. If you only test the tickets, you only test the changes people chose to declare. The real population lives in system logs, deployment pipelines and configuration history.

5. The review nobody does

Post implementation review is meant to ask a simple question: did the change do what we said it would, and did anything unexpected happen? It is usually the first step to disappear, because by then the team has moved on. Without it, failed changes and rollbacks are not analysed, and the same mistakes are repeated quarter after quarter.

What auditors should test

Good change audits start from the system, not the ticket queue.

Reconcile the population. Extract changes from deployment tools, logs or configuration history and match them to tickets. Unmatched changes are your most valuable finding.
Compare timestamps. Approval before deployment, testing before approval, closure after review.
Check who did what. Requester, approver and implementer should be different, named people.
Trend the emergencies. Volume, owners, and whether each one had a retrospective approval and review.
Follow the failures. Take a few failed or rolled back changes and see whether the lessons led to any action.

Fixing it without slowing everyone down

The answer is not more bureaucracy. Heavy processes are what drive people into the emergency lane in the first place. Classify changes by risk, and let low risk, repeatable changes be preapproved as standard changes. Spend the advisory board's time on the few changes that could genuinely hurt the business. Where teams use automated pipelines, build the controls into the pipeline itself: peer review before merge, automated tests, and no direct access to production. A control that runs every time is stronger than a meeting that reviews a summary.

Four questions for leadership

What share of last quarter's changes were emergencies, and is that rising?
Can one person build, approve and release a change to a critical system today?
How do we know every change to production went through the process?
When a change fails, who makes sure it does not happen again?

Change management rarely collapses. It erodes. The policy stays the same while practice drifts away from it, and the evidence still looks tidy. Read the timestamps, reconcile the population and follow the failures, and the quiet gaps become visible long before the Thursday night outage does it for you.