What Change Management Is For (Not Bureaucracy)

Wednesday, 08:35, at Redbrook Engineering. The first ticket says the drawings folder is "access denied". By 09:00 there are fourteen, all from the design office, all about the same share. Ingrid checks the share permissions, which are intact. She checks the file server, which is up, and the antivirus, which is quiet, and the disk, which has room. At 10:15 she opens a support call with the storage supplier. At 10:50 Rafael arrives from the dentist, hears the word "drawings", and says: "I tightened the group policy on that share on Tuesday evening so the contractors couldn't write to it. Did that break something?" It had. The revert took four minutes. The morning took two hours and twenty, three people, and a supplier call that was cancelled with an apology.

Nothing had been written down, because writing it down felt like paperwork. Change management is the habit of writing down what you are about to alter on a system people depend on. It includes letting one other person glance at it when the risk earns a glance. It also includes keeping the record somewhere it can be found afterwards. That is the whole of it. This article is part of our Lightweight Change Management series. It is about the small version: the one that fits a desk of one to ten people and costs minutes rather than meetings.

It covers the two jobs change management does and why control is not one of them. Next come the incident-after-change pattern and why "what changed?" is the first question in any outage. Then come where the bad name came from and the small version and its four parts. It covers what it costs and what it saves, with the arithmetic, and three signs a desk already needs it. It finishes with getting a team doing it without a policy, a short war story, and the change-management purpose card to copy.

The Two Jobs, and Neither of Them Is Control

Change management does two jobs. The first is not breaking things. Before a change is made, somebody other than the person making it has read what it is, when it will happen and how it will be undone. That person has had a chance to say "not on Thursday" or "that share holds the payroll exports too". The second is knowing what changed when something breaks. After the change, a record exists that says what was done, to what, by whom and when. Anyone on the desk can find it in a minute.

Control is what most people think change management is, and it is a side effect. In a large organisation the review step becomes an approval step. The approval becomes a board. The board becomes the reason nothing can be restarted before the fourteenth. None of that is the purpose. The purpose is that the change goes well and, when it does not, the desk knows where to look. A one-line record that nobody approved still does the second job in full. (It does the first one badly, which is why there are two.)

The two jobs pull in slightly different directions, which is why a small desk needs both. The first wants a pause before the change; the second wants a record after it. A desk that only does the first ends up with a weekly meeting and no history. A desk that only does the second has a tidy log of everything that went wrong. You want the pause for the changes that earn it and the record for all of them.

Stated as a test: after any change, can a colleague who was not there find out what changed? Before any risky change, did someone who was not making it read the plan? If both answers are yes, the desk has change management, whatever it calls it and however few forms it fills in. If either answer is no, it has something else, however many forms it fills in.

Why "What Changed?" Is the First Question

On a small network, most things that stop working were working yesterday, and what separates yesterday from today is usually a change somebody made. Not always: disks fill, certificates expire, suppliers have outages, and hardware fails on its own schedule. But a working system that becomes a broken one overnight, with no warning and no error, has very often been touched. And the touch was by someone in the building. That makes "what changed?" the highest-value question in any troubleshooting, and the one worth asking before the logs, before the supplier, and before the reboot.

The question has two possible experiences. With a record, the technician opens the change log and reads the last seven days. They see "Tue 18:10, drawings share, group policy tightened, Rafael", and test that first. Two minutes. Without one, the question goes round the room, then round the chat, then waits for the person who is at the dentist. The fault is the same either way; the search for it is not. The record does not prevent the outage. It shortens the mystery, and the mystery is most of the cost.

The question belongs in the first minutes of an incident, and the drill in Declaring and the First Fifteen Minutes puts it there. The point for this article is simpler. The question can only be answered if the answer was written down. It was only written down if somebody decided, before the change, that writing it down was part of making it. That decision, repeated until it is a habit, is change management.

The Incident-After-Change Pattern

The pattern has a shape, and once you have seen it you will recognise it from the first ticket. A change is made outside working hours, usually by one person, usually to fix one thing. The next morning, tickets arrive about a different thing, in a cluster, from people who have nothing in common except that they use the system that was touched. The desk works the tickets as separate problems, because that is what they look like. Eventually someone asks whether anything was changed. Eventually someone remembers.

The expensive phase is the middle one, and on most desks it has a name: "it's not the network". The desk proves, carefully, that the fault is not the thing the tickets say it is. The printers are fine. The file server is up. The login works for the technician, who is not in the contractors' group. Each step is sound. Each step is also an hour nobody gets back, because the fault was never where the tickets pointed.

Here is the Redbrook morning as a timeline, with the version that had a record beside it. The first column is what happened. The second is what would have happened if Rafael had typed one line into the change log before going home on Tuesday. The times are invented but the shape is not. I have lived both columns, and I prefer the second.

The second column is not a fantasy of a perfect desk. It is the same people, the same fault and the same fix, with one line of text added on Tuesday evening. The line took Rafael longer to feel guilty about than it would have taken to type. That is the whole return on the investment, and it is the only arithmetic this subject needs.

Where the Bad Name Comes From

Change management has a bad name because the version most people have met deserves one. In a large organisation it looks like this: a form with thirty fields and a board that meets on Thursdays. There is a lead time of ten working days, and a category called "standard" that nobody has ever managed to get a change into. The desk waits two weeks to restart a service. The board approves four hundred changes a quarter and reads none of them. Everybody involved is competent, and the process still produces a fortnight's delay in exchange for nothing.

That version exists for reasons that do not apply to you. A bank with six hundred changes a week cannot have each one read by the people it affects. So it needs a board to sample them. A regulated company must show an auditor that every change was approved, so it needs the form. A business with teams on three continents needs lead time because the people who need to know are asleep. None of that is true of five people on one site who can see each other's screens. A change advisory board (CAB) is a scheduled meeting where representatives of the affected teams approve or reject planned changes. It is a reasonable answer to a problem you do not have.

The mistake is to import the big version whole. That is the ITIL mistake in miniature, and the one described in full in our article on the ITIL processes that drown small teams. The small desk copies the form, the board and the lead time, and runs it for three months. It abandons the whole idea because the meeting was the only part anyone noticed. What should have been kept was the idea underneath: write it down, let someone glance at it, keep the record. The process was never the point. The process is what large organisations build around the point once they can no longer see it.

So when a colleague says "we don't want change management, we're not that kind of place", agree with them about the board and the form. Then ask what changed on Tuesday. The answer to the second question is the small version. Most people, offered it in those words, want it.

The Small Version

The small version has four parts, and each is the smallest thing that does its job. The first is a record: one page for a change that carries risk, one line for a change that does not. It is written before the change by the person making it. What goes in it, and how to write it in five minutes, is the subject of The One-Page Change Record. For this article, a record is a sentence with a time, a system, a before, an after and a name.

The second part is a sort. Not every change needs a second pair of eyes; most do not. The desk keeps a short written list of changes that are pre-approved as a type. They are low-risk, repeatable and done the same way each time: a new user account, a group membership, a laptop built from the standard image. Everything not on the list gets a glance from someone else before it happens. Everything that cannot wait gets the glance afterwards. That sort produces three kinds of change, and the rules for sorting are in What Needs Review and What Does Not.

The third part is a glance, and it takes fifteen minutes a week. The people who make changes sit together, or stand, or open a chat thread, and read this week's planned changes aloud: what, when, rollback, who. Someone says "not Thursday, payroll runs Thursday". Someone says "I'm touching that switch too, let's do both in one window". That is a small team's entire change board, and it costs less than the coffee round.

The fourth part is a place: somewhere the records live that everyone can search. A change department in the help desk tool, a subject prefix, a dated list in the knowledge base. The only requirement is that a person who did not make the change can find it, by date or by system, in under a minute. Most small-team help desk tools have no change module and a full ITSM suite has one. The convention works with either, and building it is the whole of Tracking Changes Without a Change Module.

That is the small version: a record, a sort, a glance, a place. None of the four is a form with thirty fields. None needs a meeting that anyone outside the desk attends. Together they pass the test from the first section. A desk that runs them will go months without anyone saying "did anyone change anything?" aloud. I have come to think of that sentence as the sound of money leaving the building.

What It Costs and What It Saves

The cost is minutes, and it is worth counting them honestly, because "it takes too long" is the objection you will hear first. Suppose a desk of four makes twelve changes in a typical week: three that carry risk and nine that are routine. The three risky ones get a one-page record at five minutes each, fifteen minutes. The nine routine ones get a one-line entry at thirty seconds each, five minutes. The weekly review is fifteen minutes for four people, an hour of staff time. Call it an hour and twenty minutes a week for the desk, or twenty minutes per person.

The saving is hours, and they arrive in lumps. One mystery outage of the Redbrook kind costs two or three hours for two or three technicians. Add the people who could not work, plus the supplier call that was never needed. On a desk making twelve changes a week, a morning like that comes round about once a month without a record and almost never with one. One avoided morning a month pays for the month's records twice over, before counting the forty designers who got their drawings back at 09:40 instead of 11:20.

There is a second saving that is harder to count and larger. A desk with a change record learns from its changes. The review notices that the same server has been patched four times and broken twice. The log shows that one technician's changes never need rolling back and another's often do. And that pattern is a training conversation rather than a disciplinary one. Read backwards, the record of what was changed is the story of how the environment came to be the way it is. It is a document every new technician wishes existed and almost none inherits.

Against that, the cost of not doing it is invisible, which is the whole difficulty. Nobody books two hours and twenty minutes to "change management, absence of". It is booked to the fourteen tickets, which are closed, and to the supplier call, which is cancelled, and to the morning, which is over. The cost is paid every time. It is just never invoiced.

Three Signs You Already Need It

Some desks are not sure whether they need this yet, and three signs answer the question inside a fortnight. Watch for them rather than asking the team, because the team will say the desk is fine, and the signs will not.

• "Did anyone change anything?" is said aloud, in earnest, more than once a month.
• A fix has had to be undone because it broke something the fixer did not know depended on it.
• A technician asked what they changed last Tuesday cannot answer without opening a console to look.

One sign is enough. Two is a desk that is already paying for change management and not receiving it. Three is Redbrook, and the thing to do about Redbrook is not a policy but a habit, which is the next section. There is a fourth sign worth adding: a thick folder called "Change Requests" that nobody has opened since the audit. That is the big version, abandoned, and it means someone tried once and gave up at the meeting.

Getting the Team to Do It

Change management on a small desk is a habit, and habits are not installed by policy. The eleven-page document saying all changes must be recorded will be read once, agreed with, and forgotten by the next outage. What works is smaller and more personal: the lead goes first, visibly, writing a record for their own change and reading it aloud at the review. The second person copies the lead. The third copies the second. Inside a month it is what the desk does, and the policy, if one is ever written, describes an existing habit instead of requesting a new one.

Make the record the easy path. Writing a change record might mean opening a separate system, logging in, filling a form with mandatory fields and waiting for an e-mail. In that case, the record loses to memory every evening at 17:30. Or it might mean typing one line into a ticket with a known prefix, or filling seven short fields in a template already open on the second screen. In that case, the record wins. The amount of change management a desk does is set by the friction of the record, not by the wording of the policy. Lower the friction and the records appear on their own.

Then make the record useful to the person who wrote it, quickly, so that it is not paperwork. Read the records at the review, so the writer sees them being used. When an incident starts, open the log first and say so out loud: "Checked the change log, nothing in the last week touches mail, so it is not us." When the log finds the cause, say that too. A record that catches one outage in its first month becomes a habit the team defends on its own.

And never punish the record. The technician whose recorded change broke something has done the right thing twice: they made the change properly and they made it findable. A desk that treats the record as evidence against its author will get fewer records, not fewer breakages. It will be back to asking the room what changed within a quarter. Praise the person who writes "my change at 18:10 may have caused this" in the incident ticket. They have just saved the desk two hours, on a morning when staying quiet would have been easier.

A Short War Story: The Long Weekend at Meridian Parts

Meridian Parts, a distributor with forty warehouse pickers and a desk of three, lost a Monday to a DNS forwarder. Keiko had changed the forwarder on Friday at 17:50, to a faster resolver a supplier had recommended. She tested it from her own desk and left for a long weekend. The handheld scanners in the warehouse looked up the stock server by a name that the old forwarder resolved from an internal zone. The new forwarder did not, so from 06:00 on Monday no scanner could reach the stock server. The two technicians on duty spent the morning on the scanners, the wireless, the stock server and a forty-minute call to the scanner supplier. Keiko was unreachable, as people on long weekends are entitled to be. The forwarder was found at 14:20 by a technician who opened the network settings for an unrelated reason. The cost was a day's picking for forty people, two lorries that left half-loaded, and a supplier call that was never needed. None of it was Keiko's fault for making the change, which was a good one. The lesson Meridian wrote on the wall was that a change nobody can find is a change that happened to the desk, not one the desk made.

The Change-Management Purpose Card

The card below is one page that says why the desk records changes, what counts, and what everyone does. Pin it where the desk can see it, put it at the top of the change log, and read it to each new technician in their first week. It is deliberately short, because a purpose that needs two pages has already lost the argument. Fill in the blanks for your own desk and change the wording wherever your tool uses different words.

CHANGE MANAGEMENT — WHY WE DO IT (ONE PAGE)
Desk: ______________________   Card owner: ______________   Last read: ______

THE TWO JOBS
  1. Not breaking things: someone other than the doer reads a risky
     change before it happens and can say "not then" or "not like that".
  2. Knowing what changed: when something breaks, anyone on the desk
     can find every change from the last seven days in under a minute.

WHAT COUNTS AS A CHANGE
  Anything that alters how a system people depend on behaves:
  settings, rules, patches, hardware, accounts with wide access,
  scripts and scheduled tasks, and anything done "just to try it".
  Not a change: fixing one person's problem inside existing settings.

THE THREE KINDS
  Standard   on the pre-approved list, done the written way
             : one-line record, no review
  Normal     everything else
             : one-page record, read at the weekly review
  Emergency  waiting for the review would cause harm now
             : tell one person first, record within one working day

WHAT WE WRITE, EVERY TIME
  What (system, setting, before, after)   When   Who   Rollback
  Where the records live: ______________________________________

WHAT WE DO
  [ ] Write the record before the change (within a day for emergencies)
  [ ] Bring normal changes to the weekly review: ______day at ____:____
  [ ] In any incident, read the change log before anything else
  [ ] Close the record with the outcome: done / rolled back / partial

WHAT WE NEVER DO
  [ ] Change a shared system on a Friday evening without a record
  [ ] Blame the person whose recorded change caused an incident
  [ ] Let the record grow into a form nobody fills in

THE TEST
  Pick any outage from the last quarter. Could someone who was not
  there have found what changed in the week before it, in a minute?
  [ ] yes   [ ] no: what is missing? ____________________________

Redbrook now has one of these above the desk. Rafael's change stayed in, with a better version applied after the following Thursday's review. The log has one line per change, and the review takes twelve minutes most weeks. The rule when tickets arrive in a cluster is that the log is opened before anything else. The last time Ingrid asked the room what had changed, the room pointed at the screen.

Frequently Asked Questions