ITIL Change Enablement Practices Without the Bureaucracy

ITIL arrives in engineering organisations as a set of forms and a board, and gets resented accordingly. The forms are the part ITIL 4 explicitly moved away from — which makes the resentment a response to an implementation nobody has updated.

In ITIL 4, the practice previously called change control was renamed change enablement.

That reads like consultancy wordsmithing and isn't. Control asks how do we stop bad changes? Enablement asks how do we make good changes safe to ship quickly? Those two questions produce different processes from the same starting materials, and they disagree about what a delay costs.

Aldermoor Health's process was written against a v3 handbook and never revisited. Every artifact in it had a defensible origin. The result was an eleven-step path that a hundred per cent of changes passed, which is exactly what control looks like when it has stopped discriminating.

What to keep, and what the newer framing already dropped

Most of ITIL's change practice is genuinely useful. The problem is that implementations keep the whole set rather than the parts that route information.

Practice	Verdict	The reason
Three change types	Keep	The single highest-leverage piece — see standard, normal, emergency
Change authority	Keep, decentralised	v4 explicitly says authority should sit as close to the work as risk allows
Change schedule	Keep	Genuinely useful: it's how you see two changes colliding on a Thursday
Risk assessment	Keep, simplified	Two questions — reversible? blast radius? — beat a nine-box matrix
CAB	Keep, reformed	Only for cross-team and hard-to-reverse: running one
Every change to the board	Drop	v4 doesn't ask for it; v3 implementations assumed it
Multi-level sign-off	Drop	Ratification, not review
Change freeze periods	Drop, mostly	Batches risk into one window and makes the release riskier
Separate CMDB upkeep by hand	Drop	Stale within weeks; use live dependency data instead

The middle rows are where most of the value sits and where implementations under-invest. The bottom rows are what people mean when they say "ITIL", and three of the four aren't required by the current framework at all.

The test you can run: for each artifact in your process, check whether it comes from the framework or from a local decision made after an incident. Most of the heavy ones turn out to be local, which means they can be changed locally.

Decentralised authority is the change that actually removes the bureaucracy

The single most useful thing in ITIL 4, and the most consistently ignored, is that the change authority doesn't have to be one central body. It's a role, assignable per change type, and it's meant to sit as close to the work as the risk allows.

That means it's legitimate — within the framework, not despite it — for a team to be its own change authority for its own reversible, single-service changes.

Aldermoor's model now:

• Standard changes — authority is the catalogue. No human in the path.

• Normal, single team, reversible — the team's own reviewer is the authority.

• Normal, cross-team or hard to reverse — the board.

• Emergency — the engineer, with review afterwards.

Nothing there is a deviation from ITIL. It's what the framework describes and what v3-era implementations usually didn't do, because a single central authority is simpler to write down.

The test: ask who your change authority is. If the answer is one group for everything, you're running a v3 implementation regardless of which version the documentation cites.

The change schedule is the underrated one

Buried under the artifacts people argue about is the one nobody objects to and few maintain: a single visible calendar of what's changing when.

Its value isn't approval. It's collision detection — the thing that catches a database upgrade and a load test scheduled for the same Tuesday afternoon, planned by teams with no reason to know about each other.

What makes one useful:

• One place, not per-team. Two calendars detect nothing.

• Forward-looking by weeks, not a log of what already happened.

• Includes non-deployment changes — certificate rotations, vendor maintenance windows, data migrations, someone's planned load test.

• Automatically populated wherever possible. A calendar maintained by hand is accurate for about a fortnight.

Aldermoor caught three collisions in the first quarter of having one. None would have been caught by the board, because each individual change was fine — the problem was only visible in the conjunction. A schedule is also where release management and change management meet, since a bundle with a date is exactly what it records.

The test: can you see, right now, everything changing in your production environment next Thursday? If that requires asking three people, you don't have a schedule.

Where heavier process is genuinely correct

Arguing for lightness generally is as lazy as arguing for control generally. Some contexts justify the heavier end, and it's worth being specific so the argument doesn't get applied where it doesn't belong:

• Regulated environments where you must demonstrate control to an auditor. The audit trail becomes a deliverable in its own right. Even here the trick is to make the trail a record of the routing that already happens rather than extra steps performed for the file.

• Irreversible changes with high consequence — anything touching money already moved, patient records, physical systems.

• Environments where you cannot observe failure quickly. Process substitutes for feedback. If a bad change takes a month to surface, more up-front scrutiny is rational.

• Immediately after a serious incident, temporarily and explicitly, with a date to revisit. The failure is when temporary tightening becomes permanent by inertia — which is how most eleven-step processes were born.

The test: for your heaviest step, name which of these four applies. If it's the fourth and the incident was two years ago, the revisit is overdue.

The audit question, answered directly

The objection to lightening a process is usually "the auditor requires it." Occasionally true, more often assumed.

What auditors generally ask for is evidence that changes are authorised, recorded, and reviewed — not that authorisation is centralised or that a board meets weekly. A delegated authority model with a complete log satisfies the requirement, provided the delegation is written down and followed.

The practical form: document who is authorised to approve what, and make the log complete. That is a page, and it does more for an audit than a heavyweight process nobody follows consistently — because the thing that fails an audit is not lightness, it's a process that's documented one way and practised another.

The test: read your own process document and compare it against what actually happened for the last five changes. The gap is your audit exposure, and closing it usually means simplifying the document.

What to change this week

Find out which version of ITIL your process was written against, and when it was last revisited. If the answer is v3 and never, you're maintaining a control process inside a framework that stopped asking for one in 2019.

Then change one thing: write down a delegated change authority. Which classes can a team approve for itself? That single page removes more delay than any other edit, and it moves you toward the framework rather than away from it.

Aldermoor's process is four steps now, and still passes audit. The auditor's only comment was that the delegation should be dated and reviewed annually, which it now is.