Change management, and the plan that exists before anything is changed

Why this matters

Change management is the part of this exam that sounds most like bureaucracy and is most directly about avoiding outages. Almost every significant unplanned outage is caused by a planned change: an update, a configuration edit, a firmware upgrade, a certificate renewal that was not renewed.

The exam asks about the components of a change request and the order they come in. The reason to learn it properly is narrower and more useful: a technician who can write a change with a rollback plan is a technician whose changes can be approved quickly, and one who cannot is the reason the process feels slow.

The lesson

Why change control exists, argued from an outage rather than from a standard

Here is the argument, from an outage rather than from a standard.

A technician updates the firmware on the office router on a Tuesday afternoon. It is a sensible thing to do — the hardening lesson in this course says so. The update resets the configuration to defaults. The port forward that the accounting system needed is gone, the wireless passphrase has reverted, and nobody can print. It is 4pm, the person who knows the configuration is the person who just changed it, and there is no record of what it was.

Everything that would have prevented that is change management:

• A record of the current configuration before the change.
• A stated reason, which prompts the question of whether now is the right time.
• A risk assessment, which would have noted that firmware updates reset configuration.
• A time window that is not the middle of a working afternoon.
• A rollback plan, which here is a saved configuration file.
• Somebody told in advance, so the first anyone knows is not the printer.

None of that is a form for its own sake. Each item maps to one of the things that went wrong. That is the way to hold this objective: every element of a change request exists because of a specific failure, and knowing which makes the list memorable rather than arbitrary.

The request: purpose, scope, risk analysis and who has to approve it

A change request answers four questions, and a request missing any of them is the reason approvals are slow.

Purpose. Why this change, and why now. "Apply the June security update, which fixes a remotely exploitable vulnerability" is a purpose. "Update the server" is not. The purpose is also what justifies the risk, so a change with a weak purpose should be questioned.

Scope. What is affected — which systems, which users, which services. The scope is what tells everyone else whether this concerns them, and underestimating it is the most common defect in a change request. A change to the authentication server affects everything that authenticates, not just the authentication server.

Risk analysis. What could go wrong, how likely, how bad, and what reduces it. Three specific things to include: what happens if the change fails half-way; what happens if it succeeds and has an unexpected effect; and what depends on this that nobody has thought about. Also the risk of not doing it, which is the half that gets omitted — deferring a security patch is itself a risk decision.

Approval. Who is entitled to accept this risk. Not the technician, for anything significant: the point of approval is that somebody who owns the consequences agrees to them. Emergency changes have a faster route and are documented afterwards, which is a legitimate path and not a way around the process.

The plan: steps, timing, communication, and who is told and when

The plan is what someone else could execute, and writing it as though somebody else will is what makes it good.

Steps. Numbered, specific, in order, with the exact commands and values. A plan written in generalities is a plan being made up on the night.

Timing. A maintenance window when the affected users are not working, with enough time for the change and the rollback. The most common scheduling error is allowing time for success only.

Communication — who is told, and when:

• Before: everyone affected, with what will be unavailable, when, and for how long. Far enough ahead that people can plan, and again shortly before.
• During: whoever is on the change, and a way to reach whoever can decide if something unexpected happens.
• After: confirmation that it is done and that things are working, and a request to report anything odd.

Who else needs to know: the service desk, above all. A change nobody told the service desk about generates tickets that are diagnosed from scratch, which is pure waste.

The other half of the plan: who is doing it, who is available if it goes wrong, and what the decision point is — the time at which, if it is not working, you stop and roll back rather than continuing to fix. Deciding that in advance is what stops a two-hour window becoming a six-hour outage, because at 2am nobody makes that call well.

The rollback plan, which is the part that makes the change safe to attempt

The rollback plan is what converts a risky change into an attempted one, and it is the part most often written as a single word.

"Restore from backup" is not a rollback plan unless you can say: which backup, where it is, how long the restore takes, who has done one before, and whether it has been tested. Otherwise it is a hope.

What a real rollback plan contains:

• The exact steps to reverse the change, in order.
• How long they take. If the rollback takes four hours and the window is two, the plan does not fit and the change needs rescheduling.
• The artefacts it depends on — the saved configuration, the exported settings, the uninstall package, the previous firmware image — and confirmation that each exists and has been tested before the change begins.
• The point of no return, if there is one. Some changes cannot be reversed after a certain step — a schema upgrade, a one-way conversion, a firmware update with no downgrade. Identifying that point is essential, because everything before it is safe to attempt and everything after it is committed.
• Who decides to invoke it, and when.

The discipline that makes it real: capture the current state as the first step of the change itself. Export the configuration, screenshot the settings, note the version, take the snapshot. Doing it as step one rather than as preparation means it cannot be skipped when the window is tight — which is exactly when it is skipped.

After the change: testing, documenting and closing it properly

The change is not finished when it works. Three things close it.

Test. Test the thing you changed, and test the things that depend on it. A firewall rule change is tested by trying the traffic it was meant to allow and the traffic it was meant to block. A server update is tested by the applications that use the server, not by the server starting. Where possible, have a user confirm, because the technician's test and the user's workflow are rarely the same.

Document. What was changed, by whom, when, and what the result was. Update the network documentation, the asset record and the configuration store at this point, not later. Record anything unexpected even if it did not cause a problem, because it is the first datum in a pattern nobody has noticed yet.

Close. Tell the people who were told in advance that it is done. Close the change record with its outcome. Leave a monitoring period — an hour, a day, a week for something significant — and say who is watching and for what.

And when it went wrong, the closure is more valuable rather than less: what happened, what was rolled back, what was learned, and what would be done differently. A failed change that is documented honestly is how an organisation gets better at this; one that is quietly reversed and never mentioned is how the same failure happens again next year, to somebody else, who will have no idea it has happened before.