Change Management on ServiceNow: Why Your CAB Discipline Is Quietly Wrecking Your Change Failure Rate

A platform lead at a European insurer asked me last month to look at their change process on ServiceNow. Their board had just been shown a slide with a 14 percent change failure rate and the CIO wanted to know whether it was a tooling problem or a people problem. He was hoping for tooling, because tooling is buyable.

I spent two days pulling change records, listening in on a CAB, and sitting with the Change team. The tool was fine. The CAB was theatre. Every Wednesday at 15:00 a room of twelve people spent ninety minutes rubber-stamping fifty-plus normal changes, arguing about two of them, and running out of time before the standard change catalogue was even mentioned. Nobody was reading the change records before the meeting. The risk score was cargo-culted from the template. The implementation plans were three sentences long. The failure rate had nothing to do with the platform. It had everything to do with the fact that change management servicenow had become a compliance ritual instead of a control.

This is the pattern I see in nine out of ten mid-market instances. The tool is doing what you told it to do. The discipline around it collapsed years ago and nobody noticed because the reports still turn green.

What “good” actually looks like

I want to be concrete about what a working change process on ServiceNow feels like, because most people have never seen one.

Good looks like a CAB that lasts thirty minutes because the reviewers have already done the reading and marked their positions in the change record before they walk in. Good looks like a change advisory board that spends most of its time on the two or three genuinely contentious changes and lets the rest go through as pre-approved. Good looks like implementation plans that a stranger could execute at 3am, not paragraphs of “will deploy the change according to the runbook”. Good looks like a post-implementation review that actually happens on every failed change, not just the ones somebody escalated.

None of this is a ServiceNow feature. All of it is the thing ServiceNow enables if you have the operating model to match. When people ask me to fix their change process, ninety percent of the work is not in the platform.

The five ways CAB discipline erodes

Once you know what to look for, the erosion pattern is boringly consistent.

The first is scope creep on normal changes. Standard changes drift out of the catalogue because nobody has time to maintain it, so what should have been a pre-approved template becomes a normal change with a risk score of “low” and no real scrutiny. Six months later the CAB is drowning in fifty low-risk normals per week and the model has effectively collapsed into “everything goes through CAB”.

The second is the risk score becoming a lie. The default risk calculation on your instance was set up by an implementation partner who left three years ago. Nobody has revisited it. Everything comes out as low or moderate because the CI relationships in the CMDB are stale, so the risk calculation cannot see that a change to a shared authentication service touches half the estate.

The third is CAB attendance drifting to the wrong people. The original approvers were architects and senior operations leads who could actually read an implementation plan. Over time they delegated to team leads, who delegated to on-call engineers, who send a proxy when they cannot attend. Now the CAB is a room of people who cannot say no because they lack the authority, and cannot say yes with confidence because they lack the context.

The fourth is post-implementation review theatre. The PIR task auto-generates on every change and auto-closes seven days later with a boilerplate “no issues observed”. Nobody has time to actually go and check. Your incident-caused-by-change data becomes fiction because the linking between the incident and the change is done by hand and nobody remembers.

The fifth is the change failure rate metric itself becoming meaningless. If a change causes an incident that shows up three days later during month-end processing, does that count against last week’s change record? On most instances I audit, the answer is “no, because nobody linked them”. The reported change failure rate is a rolling twelve-month lie.

Where the boutique advantage actually shows up in ITIL best practices

I want to be honest about where big-partner change management engagements go wrong, because this is a topic where the boutique versus Big 4 argument is not marketing.

A Big 4 change engagement typically arrives with a forty-page target operating model, a RACI matrix, a governance forum diagram, and a three-month workshop cadence. All of it is technically correct. Almost none of it survives contact with your actual on-call engineers, who will keep raising standard changes as normals because the standard-change catalogue is a pain to maintain and nobody has ever shown them how to submit a template proposal.

The boutique version of this engagement is smaller and more surgical. You spend a week actually reading three months of change records and coding them by risk category. You spend a day sitting with the CAB and watching the discussion. You spend two days with the standard-change owners going through the top ten most-frequent normal changes and asking why they are not standards. You leave with a shortlist of ten catalogue items to build, a redesigned CAB agenda that fits in forty-five minutes, and a risk calculation that reflects the current CMDB. Then you actually build the ten items and prove the model works before you write the operating-model deck.

This is not because boutique consultants are cleverer. It is because we cannot afford to sell workshops. We have to leave you with something that works in three weeks or you fire us.

The CMDB question you cannot avoid

Every serious conversation about change management servicenow eventually collides with the CMDB. Your risk calculation, your affected-services list, your impact analysis, and your change collision detection all depend on the CMDB reflecting reality. On most mid-market instances it does not, and everyone knows it does not, and the fix has been on the roadmap for two years.

You do not need to boil the ocean here. You need to identify the twenty or thirty CIs that touch fifty percent of your changes and get those relationships right. That is usually the authentication stack, the core network, the main database estate, the ERP, the primary customer-facing web tier, and a handful of shared platform services. If those relationships are accurate, your risk calculation starts telling the truth for eighty percent of your change traffic. The long-tail CIs can wait.

I write about this in more detail in our approach to CMDB governance as a product rather than a one-off cleanup. The short version is that the CMDB gets cleaned up when a team owns it as an ongoing product with a small backlog, not when it is a project that ends.

Where to start, practically

If your change failure rate is above ten percent and your CAB feels like theatre, here is where I would start on Monday morning.

Pull ninety days of normal changes and hand-code them by real risk. If more than a third of your normals are actually low-risk repeat changes, you have a standard-change catalogue problem, and that is the first thing to fix because it decompresses the CAB.

Attend a CAB as an observer with a stopwatch. Note how many minutes are spent per change and how many changes never get discussed. If the average discussion time per change is under two minutes, your CAB is not reviewing anything, it is signing.

Audit your risk-calculation script and the CI data it depends on. If the script has not been touched in two years and the CIs are stale, your risk score is decoration. Rebuild it against the twenty or thirty CIs that matter most.

Turn on the post-implementation review as a real workflow with named owners and a two-day SLA. Kill the auto-close. If a PIR is not completed, the requester cannot raise their next change. That single rule fixes more discipline problems than any governance forum ever will.

Closing

Change management on ServiceNow is one of the areas where the platform gets blamed for a problem it did not cause. The tool is doing what you configured it to do. The CAB is signing what you put in front of it. The change failure rate is telling you what you asked it to measure. If any of that is broken, the fix is upstream of the platform, in the operating model and the CMDB and the discipline around them.

If you want to know whether your change process is genuinely healthy or just producing green reports, the 10-Day Instance Health Report walks through your change data, your CAB records, and your CMDB alongside the platform config. Fixed fee, two weeks, a scored report you can hand to your CIO. That is where I would start if I were you and I wanted an outside read before committing to a bigger change programme.

Mladen Milic runs Milic Media Kft, a boutique ServiceNow consultancy delivering implementation, health audits and HRSD work across the EU. Reach him at mladen@milicmedia.com.