The Difference Between Standard, Normal, and Emergency Changes

The three change classes are usually taught as definitions to memorise. They're better understood as a routing decision, and there is one number that tells you whether yours is working.

Aldermoor Health ran about 340 changes in a quarter. 338 were classified "normal" — the class that requires a full record, a dependency check, and review at the weekly board.

The standard-change catalogue had two entries: password reset and certificate renewal. Both were added in the first month of the process being introduced. That was three years earlier.

Nobody had decided this. Each individual classification was defensible — when the choice is "standard, if it's pre-approved" and nothing is pre-approved, everything is normal by default. The catalogue was empty because filling it was nobody's job, and the process quietly became one-size-fits-all.

The classes exist to let most changes skip the process

That's the point, and it's the part that gets lost when they're presented as three definitions.

• Standard — pre-approved, because we've done it enough times to know what it does. No review, no waiting. Just do it and log it. (The three classes come from ITIL, and they are the part of it most worth keeping.)

• Normal — needs assessment because we can't predict the outcome from experience alone.

• Emergency — the assessment happens after, because waiting costs more than being wrong.

A healthy process pushes as much as possible into the first class. That's not corner-cutting; it's the mechanism by which the process stays affordable enough that people use it rather than routing around it.

The number that tells you: what proportion of your changes are standard? Under about half and your catalogue is starving. At Aldermoor it was 0.6%.

The test you can run: open your standard-change catalogue. Count the entries, and check when the last one was added. If it's been over six months, nothing is being promoted, and the class is decorative.

The promotion rule that fills the catalogue

The catalogue stays empty because promoting something feels like a risk decision nobody wants to own, so it needs to be mechanical rather than a judgement call.

The rule Aldermoor adopted: done three or more times, no incident attributable to it, and a documented rollback → promote to standard. Reviewed monthly, five minutes, from the change log itself.

The first month produced eleven promotions from the existing log — deployment of a service with no schema change, adding a read replica, rotating a service credential, scaling a node pool. All of them routine, all of them previously paying full price.

Two properties make this work:

• It's evidence-based, not opinion-based. The change log already knows what you've done repeatedly without incident. Nobody has to predict anything.

• It's reversible. A standard change that causes an incident gets demoted, and that has happened twice. Demotion being cheap is what makes promotion safe.

The test: run the rule against your last quarter's change log right now. Count how many distinct change types clear the three-times-no-incident bar. That number is what your catalogue should already contain.

What each class actually costs

	Standard	Normal	Emergency
Approval	Pre-approved — none at the time	Required, before	After the fact
Who decides	The catalogue	The change authority or CAB	The engineer on the spot
Record	Logged after, minimal	Full, before	Full, reconstructed after
Dependency check	Done once, at promotion	Every time	Skipped — and this is the real cost
Should be	most of them	the genuinely novel	rare, and always reviewed
Aldermoor before	0.6%	99%	~0.4%

The row that deserves attention is the dependency check. Standard changes skip it safely because it was done once at promotion and the change hasn't varied since. Emergency changes skip it unsafely — that's the trade you're making, and it's why the emergency class needs a review afterwards rather than a pass.

The test: for each class, name what it skips and why that's acceptable. Emergency should be the only one where the honest answer is "it isn't, we accepted the risk".

Emergency is a class, not an escape hatch

The failure mode is predictable: emergency becomes the lane people use when normal is too slow. Once that starts, the classification stops carrying information — you can no longer tell a genuine outage response from someone with a deadline.

Two mechanics keep it honest, and neither is about permission:

• Every emergency change gets reviewed afterwards, without exception — not to assign blame, but to answer one question: would waiting have been worse? Sometimes the honest answer is no, and that's fine to say once. Said three times by the same team, it's a finding about the normal lane being too slow.

• Emergency rate is a metric with a direction. Rising means the normal path isn't usable. Falling to zero across a whole year is also suspicious — it usually means people stopped classifying honestly, not that nothing urgent happened.

The thing that does not work is making emergency harder to invoke. That doesn't reduce emergencies; it reduces recorded emergencies, and you lose the signal.

The test: count your emergency changes last quarter and ask, per change, whether waiting would genuinely have been worse. If more than a couple come back "no", the normal lane is the problem being reported.

When the classification stops helping

Three cases where this framework is the wrong tool, and forcing it produces theatre:

• Continuous delivery at high frequency. If you ship forty times a day, classifying each one is absurd. The pipeline itself becomes the standard-change definition — anything that passes it is pre-approved by construction. Which is the same idea, implemented in code rather than a catalogue.

• The change is a decision, not an action. Choosing a database is not a change record. It's an architecture decision, and it wants a different artifact.

• The organisation is small enough to route by conversation. Below roughly a dozen engineers on one system, the classification overhead can exceed the coordination it buys. Keep the record, skip the classes, until a second team depends on you.

That last boundary matters because a process introduced too early gets resented, and the resentment outlives the size that justified it.

The test: if a change ships through an automated pipeline with tests, a canary and an automatic rollback, ask what the classification adds. Often the answer is a log entry, which the pipeline can write itself.

What to change this week

Take last quarter's change log, group by what kind of change it was, and count. Anything you did three or more times without an incident and can roll back is a standard-change candidate.

Promote them in one sitting. Then put the review in a monthly calendar slot, five minutes, and let the catalogue grow from evidence you already have.

Aldermoor's standard rate went from 0.6% to about 60% in two months — not by loosening anything, but by writing down what they had already been doing safely for years. The board went from twenty-six changes a meeting to six, which is the only reason the remaining six get real attention.