Changes Don't Fail on the Night. They Fail Two Weeks Earlier.

# ITIL

# Change Enablement

# AI

# Problem Management

Seven change failure patterns, the early signal each one leaves behind, and what AI is about to do to all of them.

November 6, 2026

Panos Mastrogiannis

Changes Don't Fail on the Night. They Fail Two Weeks Earlier.

Seven change failure patterns, the early signal each one leaves behind, and what AI is about to do to all of them.

Every failed change I have seen was decided before the night it failed.

The night is only where the story ends. By the time the change is implemented, the failure is already written. It was written when someone said "it's a small one", when the rollback section was copied from the last ticket, or when nobody asked the team next door.

Failed changes are not random. They repeat. Once you have seen enough of them, you stop seeing incidents and start seeing patterns, and every pattern leaves a signal days or weeks before it bites.

These are seven I would teach anyone who runs change. For each one: what it looks like, the early tell, and the move that stops it.

1. The Small One

"It's just a config change. Five minutes."

The most dangerous words in change management are "small" and "quick". Small changes skip testing, skip review and skip the second pair of eyes, because the effort of doing it properly feels out of proportion. They also tend to touch shared things: a certificate, a DNS record, a firewall rule, a timeout value. Small effort is not the same as small blast radius.

The tell: the change description is one line long, and the impact field says "none"

The move: judge risk by blast radius, not by effort. Ask one question: "If this goes wrong, how many services notice?"

One of the most expensive changes I have seen was a DNS record. It was updated on the primary side but not on the DR side. The day we redirected traffic to DR, what should have been a routine switch turned into a mess across multiple services. A one-line change, a multi-service incident.

2. The Rollback Nobody Has Run

Every change record has a rollback plan. Very few of those plans have ever been executed. Some cannot be: a database migration that transforms data, a vendor upgrade that only goes one way, a message that has already left for a counterparty. These are one-way doors, and they are usually written up as two-way doors.

The tell: the rollback section says "restore from backup" or "revert to previous version", with no time estimate and no named person.

The move: ask "when did we last actually do this rollback, and how long did it take?" If the answer is "never", treat the change as a one-way door, and plan it like one: a smaller step, a longer test, a decision point before the point of no return. And size the change window for the way back, not just the way forward.

I have seen a rollback take three times as long as the rollout. The change window had been sized for going forward, not for going back. When we had to roll back, we ran past the window, breached the availability SLA and caused impact well outside the hours we had planned for.

3. The Invisible Neighbour

The change worked perfectly. Something else broke. A batch job that read the old file format. A partner interface that pinned an old certificate. A report that nobody in IT knew the finance team ran every morning at 07:00.

Dependencies you have mapped rarely hurt you. The ones that hurt are those that live in someone's head or someone else's team.

The tell: "no impact expected", with no list of who was asked.

The move: change the question on the form from "who is affected?" to "who did you ask?" Names, not systems. A blank answer is the real risk assessment.

A team renamed some folders and files. Nobody knew that batch jobs owned by another department depended on them, so nobody asked. The batch cycles froze for days, and every day it was a different job that failed.

4. The Pile-up

Each change on its own was low risk. Twelve of them in the same window, on related services, with the same three engineers, was not. Pile-ups happen before freezes, before month-end, before holidays, and on the one night a quarter everyone agrees is "the release night".

When it goes wrong, nobody can tell which change caused it, so the rollback becomes a guessing game.

The tell: the change calendar for one window is visibly denser than any other week. People are booked on more than one change in the same window.

The move: give each window a change budget, per service and per person. When the budget is full, the next change waits, however small it is (see pattern 1). And keep production and DR work apart: different windows, or at least different people.

An administrator was carrying a long list of minor changes in the same window, on both production and DR. Moving from one to the next, he applied a configuration meant for the DR infrastructure to production. It was not a skills problem. It was a load problem, and the window made the mistake almost inevitable.

5. The Change You Didn't Make

Your SaaS provider updated their API. Your cloud provider changed a default. Your outsourced partner patched a server on their own schedule. None of these appear in your change records, but all of them change your service.

In a multi-supplier world, a growing share of the changes that hit you were never raised by you.

The tell: count your major incidents from the last twelve months that had no matching change record. That ratio is the size of your blind spot. I think it is the most underused number in service management.

The move: put supplier change notifications into the same calendar as your own changes, and make "supplier change visibility" a line in every critical contract and every service review.

A client ran planned maintenance on their side. We spent four hours hunting for the cause of an incident before their notification arrived: maintenance completed. We were told when it ended. Nobody had told us when it started.

6. The Emergency That Wasn't

Emergency changes exist for real emergencies. But when the normal process is slow, emergency becomes the fast lane. Teams learn, quietly, that "urgent" gets things done.

The tell: the share of emergency changes is rising, and the same teams or the same systems keep appearing.

The move: don't ban emergencies; review them. Ten minutes, every week: was it a real emergency, and if not, what made the normal path too slow? Usually the fix is to make the normal path faster, not to police the fast lane.

One case I remember was raised as urgent, and it was really patterns 1 and 3 together: a "small" change, pushed through the fast lane, touching something another team depended on. The urgency removed exactly the questions that would have caught it.

7. The Quiet Success

A change is closed as successful an hour after implementation. No alarms, no calls. Three weeks later, month-end processing runs far slower than usual, and nobody connects it to the change. Some changes fail slowly: performance drifts, a nightly batch overruns, a capacity limit arrives on the first busy day.

The tell: success is declared within hours, and post-implementation reviews happen only after a failure.

The move: define success before the change, in business terms, and verify it at the cycle that matters: the next batch, the next peak, the next month-end. Update every runbook and continuity plan the change touches, as part of the change, not after it. "No incident" is not a success criterion.

One production change only revealed itself during a business continuity test. The BCP instructions still described the configuration as it was before the change. The change itself had worked. Nobody had updated the recovery steps, so the failure sat waiting for the one day we would need them most.

What AI does to these patterns

This is where it gets interesting, because AI cuts both ways.

On the good side, several of these patterns are visible in data you already have, and AI is very good at spotting them. Pile-ups show in the calendar. Invisible neighbours show in configuration data and in incident history. The change you didn't make shows as incidents with no matching change. Quiet successes show as metrics that drift after a change. A model that watches your change and incident history and says "this looks like pattern 3" before the change goes in is worth more than any extra CAB meeting.

On the risky side, AI makes some patterns worse:

The Rollback Nobody Has Run, version 2.0. AI writes beautiful rollback plans. They are complete, well structured and confident, and they have still never been executed. Polish is not proof.

The Small One, at machine speed. When AI agents and automation raise and implement changes themselves, the volume of "small" changes goes up dramatically. Each one is low effort. The blast radius question matters more than ever.

The Pile-up, automated. Ten agents optimising ten services in the same hour is a pile-up nobody scheduled.

So the rule I would offer is simple. Use AI to see the patterns earlier. Don't let AI decide the changes that sit on a one-way door, and keep a named human on anything with a blast radius you can't fully see.

Your two-week test

Take your next significant change, two weeks before it goes in, and ask seven questions:

Are we judging this by effort or by blast radius?

When did we last actually run this rollback?

Who did we ask, by name?

What else is in the same window, and who is on it?

What are our suppliers changing that week?

If this were raised as an emergency tomorrow, why?

How will we know it worked, at month-end and not just tonight?

None of these questions needs a tool, a framework update or a budget. They need someone who has seen changes fail before, and who asks early enough for the answer to matter.

That is the real job of change enablement. Not to approve changes. To see the failure coming while there is still time to change the plan.

Over to you: which of these seven have you met, and which one did I miss? Bring your pattern to the Ask an ITIL Master thread on Change Enablement and AI , open in the ITIL forum from 2 to 11 November.

Coming up: The ITIL Masters Desk, December 8th

Where conversation, connection, and real-world practices come together.