Why do change advisory boards slow teams down?

Usually because they review all changes the same way on a fixed schedule. That forces teams to batch changes and wait, making changes larger and riskier. Routing low-risk changes through pre-approval or peer review and reserving the board for high-risk changes restores both speed and meaningful oversight.

What is a good change failure rate?

There is no universal target; it depends on the systems and how failure is defined. What matters is tracking it consistently and seeing it improve, along with how quickly failed changes are detected and reversed. A low failure rate achieved by making very few changes is not a good outcome.

Why do engineers bypass change management?

Because the process costs more effort than it seems to provide in safety: slow approvals, repetitive forms, and reviews that do not catch real risks. Bypasses create unrecorded risk. Reducing friction, automating evidence, and showing that reviews prevent incidents do more to stop bypassing than stricter enforcement.

What is a standard change?

A standard change is a pre-authorised, low-risk change that follows a documented, tested procedure, such as a routine certificate renewal or a scaling action. It does not need individual approval each time. Defining standard changes for common routine work frees review capacity for changes that genuinely need assessment.

Should every change go to the change advisory board?

No. Sending every change to the board makes it a bottleneck and dilutes attention. Most frameworks allow pre-approved standard changes and delegated approval for low-risk normal changes. Board review is most valuable for high-risk, cross-team, or unusual changes, where collective judgement and coordination actually reduce risk.

How do you measure whether change management works?

Track change failure rate, time to restore service after failed changes, lead time from request to implementation, the share of emergency changes, and the proportion of incidents caused by changes. Improvement means fewer and smaller change-related incidents without longer lead times. Counting approvals or completed forms does not show whether risk actually fell.

Why IT Change Management Fails, and How to Fix It

IT change management usually fails in one of four ways: approval boards become bottlenecks that review everything equally, reviews turn into rubber stamps, emergency changes become the normal route, or teams bypass the process entirely. The fixes are risk-based routing, pre-approved standard changes, automated evidence, honest post-implementation review, and measuring outcomes such as change failure rate rather than compliance.

Failure 1: the bottleneck

A change advisory board that reviews every change in a weekly meeting becomes the constraint on delivery. Teams batch changes to fit the schedule, which makes each change larger and riskier, which is the opposite of what the process intended. Meanwhile the board spends as long on a routine certificate renewal as on a database migration.

Fix: route by risk. Pre-approve standard changes that are tested, reversible, and routine. Let peer review approve normal low-risk changes. Reserve board review for genuinely high-risk or cross-team changes.

Failure 2: the rubber stamp

Reviewers approve changes they cannot meaningfully assess: vague descriptions, no information about dependencies, no test evidence, no rollback plan. The approval records exist, but they do not reduce risk.

Fix: require evidence rather than descriptions. Attach test results, affected services from configuration data, deployment and rollback steps, and recent incidents on the same components. Automate as much of this as possible from pipelines and the CMDB so it costs submitters little.

Failure 3: everything is an emergency

When the normal process takes too long, teams label changes as emergencies to get them through. Emergency changes typically receive the least scrutiny, so the riskiest path becomes the most common one.

Fix: track the proportion of emergency changes and review them afterwards. A high rate is a signal to speed up the normal path, not to tighten the emergency one.

Failure 4: the bypass

Some changes never enter the process at all: console tweaks, hotfixes during incidents, configuration edits nobody considered a change. They create configuration drift and make incident investigation harder, because the change that caused the problem is not recorded anywhere.

Fix: reduce friction so recording a change is easier than skipping it, detect unrecorded changes through drift detection and audit logs, and treat bypasses found during incident reviews as process feedback rather than individual blame.

Measure outcomes, not compliance

The purpose of change management is fewer and smaller change-related incidents without slowing delivery unnecessarily. Measure that directly: change failure rate, time to restore after a failed change, lead time for changes, and the share of incidents traced to changes. Counting approvals or checking that forms were completed measures activity, not safety. Share the outcome measures with the teams making changes, so the process is seen as a tool for them rather than a control imposed on them.

A practical reform sequence

Changing a change process works best in steps. First, measure the current state: volume by change type, lead time, change failure rate, and emergency change share. Second, define standard changes for the most common low-risk categories and pre-approve them. Third, automate evidence collection from pipelines and configuration data. Fourth, move normal low-risk changes to peer review. Fifth, refocus the board on high-risk and cross-team changes, with better information than before. Review the measures after each step, and keep what reduces risk without adding delay.

Close the loop

Post-implementation review is the step most often skipped. Reviewing failed changes, and a sample of successful ones, shows which risk assessments were wrong and which categories of change are safe enough to pre-approve. Without it, the process never learns, and the same kinds of changes keep causing the same kinds of incidents.

Frequently asked questions

Why do change advisory boards slow teams down?: Usually because they review all changes the same way on a fixed schedule. That forces teams to batch changes and wait, making changes larger and riskier. Routing low-risk changes through pre-approval or peer review and reserving the board for high-risk changes restores both speed and meaningful oversight.
What is a good change failure rate?: There is no universal target; it depends on the systems and how failure is defined. What matters is tracking it consistently and seeing it improve, along with how quickly failed changes are detected and reversed. A low failure rate achieved by making very few changes is not a good outcome.
Why do engineers bypass change management?: Because the process costs more effort than it seems to provide in safety: slow approvals, repetitive forms, and reviews that do not catch real risks. Bypasses create unrecorded risk. Reducing friction, automating evidence, and showing that reviews prevent incidents do more to stop bypassing than stricter enforcement.
What is a standard change?: A standard change is a pre-authorised, low-risk change that follows a documented, tested procedure, such as a routine certificate renewal or a scaling action. It does not need individual approval each time. Defining standard changes for common routine work frees review capacity for changes that genuinely need assessment.
Should every change go to the change advisory board?: No. Sending every change to the board makes it a bottleneck and dilutes attention. Most frameworks allow pre-approved standard changes and delegated approval for low-risk normal changes. Board review is most valuable for high-risk, cross-team, or unusual changes, where collective judgement and coordination actually reduce risk.
How do you measure whether change management works?: Track change failure rate, time to restore service after failed changes, lead time from request to implementation, the share of emergency changes, and the proportion of incidents caused by changes. Improvement means fewer and smaller change-related incidents without longer lead times. Counting approvals or completed forms does not show whether risk actually fell.