A Change Review That Takes Fifteen Minutes

Thursday, 09:00, at Tollgate Foods. Four people stand around Rosa's screen, where the week's list shows six planned changes. At minute six, the room notices that Rosa's storage firmware update and Theo's file-server patch are both booked for Friday at 18:00, on the same pair of hosts. The room also notices that if Monday goes badly nobody will know which one did it. At minute nine, Wen from finance, who comes once a month, mentions that the month-end stock valuation runs on Friday night from the file server. Both changes move to Saturday at 08:00. A third change, which Theo admits he has not yet written a rollback for, goes back to next week. The review ends at minute fourteen. There were no slides, nobody took minutes, and nobody called it a board.

A change review is the short, regular meeting where the people who make changes read each other's planned changes before they happen. In a large organisation this is the change advisory board (CAB), a scheduled committee with representatives, a chair, and a lead time. For a desk of one to ten people it is fifteen minutes a week, standing up, with the records already written. This article is part of our Lightweight Change Management series. It is about those fifteen minutes: what happens in them, who is there, and the calendar that makes them work.

It covers what a change board does and why a small desk does not need one. Next comes the fifteen-minute shape, minute by minute, with a worked week. Then it covers who comes, the change calendar, the three kinds of conflict, and freeze periods. Next it covers the questions to ask of each change, running the review with two people or one, and keeping it to fifteen. Finally come a short war story and the review agenda to copy, in that order.

What a Change Board Does, and Why You Don't Need One

A change advisory board does four things. It samples and approves the changes that are too many for anyone to read in full. It finds conflicts between changes made by teams who do not talk to each other. It protects the business periods when a change would hurt most. And it gives the affected departments a seat, so that finance can say "not on the last day of the month" before the change rather than after. Those are good reasons, and a bank with six hundred changes a week and forty teams needs every one of them.

A small desk needs three things from the same idea, and none of them needs a board. It needs a second pair of eyes on the changes that carry risk. It needs a calendar that everyone can see. And it needs the conflicts found on Thursday morning rather than on Monday morning. Fifteen minutes a week, with the records written in advance and the calendar on the screen, does all three. The board's other work, the sampling and the representation, is a solution to having more changes and more teams than you have.

Two things are lost by not having a board, and it is worth naming them. There is no formal approval. So if an auditor asks how changes are controlled, the evidence is the dated record with "read at the review on" filled in, plus the review notes. That is sufficient evidence for most audits of a desk this size. And there is no standing seat for other departments, which is why the review invites one person from outside IT once a month or whenever the calendar needs them. The person who knows when payroll runs is worth more to the review than any process document.

The Fifteen-Minute Shape

The review has four parts with the clock running. Minutes zero to two are last week's outcomes. Each change that was due to happen is read by its outcome line: done, rolled back or partial. Anything that was rolled back or partial gets one sentence on why. A record with no outcome line is asked about by name. Minutes two to ten are this week's normal changes, at ninety seconds each. The doer reads the what, the when and the rollback from the record. The room asks the questions in the section below. The change gets a window on the calendar or goes back for more work.

Minutes ten to thirteen are the calendar, two weeks ahead: collisions between changes, changes inside a freeze period, and changes whose doer or rollback expert is away that day. Minutes thirteen to fifteen are the emergencies since last week. Each is asked three things: was it one, did the fix hold, and is there a follow-up ticket? Then comes the pre-approved list, if anyone has an entry to add or strike. Then it ends. If the list of changes was not finished, the unread ones wait a week, which is the strongest incentive the desk has for bringing them earlier.

The ninety seconds is a hard number and it does most of the work. A change that cannot be read in ninety seconds has a record that is not ready. The record goes back to its author with the question that stopped it. A change that the room wants to design is a different meeting; the review parks it, names who will take it, and moves on. Ninety seconds is enough to hear a what, a when and a rollback, and ask whether the rollback has been tried. It is not enough to argue about subnet masks, which is the point.

Here is Tollgate's week as the review saw it, six changes in eight minutes. The last column is what the review found, which in a quiet week is "nothing", and in this week was two collisions and an unfinished record. The outputs are a calendar with three entries moved and one change deferred, which took Rosa about a minute to apply after the review ended.

Who Comes

Everyone who makes changes comes, and the desk lead comes, and that is the list. Nobody attends in order to approve. The review is peers reading peers, and the authority to say "not Friday" belongs to whoever spotted the problem. Once a month, or whenever the calendar needs it, one person from outside IT is invited. It is the one who knows when payroll, month-end, year-end, exams, peak trading or the audit happen. They come for the calendar minutes and leave. A manager who does not make changes gets the outcome lines by e-mail and is welcome at any review they want to see. Most want to see one.

Hold it standing, at one screen, at the same time every week, and protect the slot. If the lead is away the review still runs, with whoever is there. If the team is remote, the review is a chat thread opened at the fixed time. In that thread, each doer posts a link to their record, and the others reply with questions. The lead posts the calendar, and the thread is closed at fifteen minutes. The form does not matter. The fixed time does, because a review that floats is a review that is skipped the first busy week and forgotten by the third.

The Change Calendar

A change calendar is a shared calendar that holds every planned normal change, every freeze period, and every supplier maintenance window the desk knows about. The change number goes in the title. Most organisations already have a calendar tool everyone can see; make a new calendar in it rather than a new tool. An entry reads "CHG 7102 storage firmware, Rosa" with a start time and a duration. Freeze periods are all-day events across their span. Supplier windows are entered as soon as the supplier announces them.

The calendar's job is to make three things visible without anyone asking. The first is two changes on the same system in the same week. The second is a change inside a freeze. The third is a change on a day when its doer or the person who can roll it back is away. The third needs the leave calendar beside it, and the easiest way is to show both at once at the review. How a desk keeps its absence calendar readable is the subject of The Coverage Calendar. A change whose rollback expert is on a beach has no rollback, however carefully it was written.

Colour the entries by kind if the tool allows, and do not worry if it does not. The only requirement is that anyone on the desk can open the calendar and answer "what is changing this week?" without asking a colleague. On the morning tickets arrive in a cluster, that calendar and the change log are the first two things opened. Together they answer the first question in any incident before the second question is asked.

Conflicts: Three Kinds

A system conflict is two changes to the same system, or to systems that depend on each other, in the same window or on consecutive days. The danger is not that they collide while running. It is that when something breaks on Monday nobody can tell which change did it. The rollback of the wrong one makes two problems. The fix is to combine them into one change with one rollback and one test. Or space them by at least a working day with the test of the first done before the second starts.

A business conflict is a change during the period when the system matters most to the people who use it. Month-end for finance, the payroll run, exam week for a school, the Saturday before a holiday for a retailer, the morning of the board meeting for the one system the board looks at. The desk cannot see these from inside IT, which is why the outside person is invited and why their dates go on the calendar as freeze periods the moment they are known.

A people conflict is a change on a day when the doer, the second person, or the only person who can roll it back is away, on a course, or alone on the desk with the phones. The fix is to move the change or the person, and it is nearly always the change. The review finds this by looking at the leave calendar alongside the change calendar, which takes thirty seconds and is skipped by every desk that has not yet been burned by it.

Freeze Periods

A freeze period is a stated span during which no normal changes are made to named systems. It is declared by the review, written on the calendar as an all-day event, and has a start, an end, and a list of systems. It is not "no work". Incidents are still fixed. Standard changes continue unless the freeze says otherwise. Emergency changes happen under the usual rules. What stops is the planned, normal change to the finance system in the three days when finance is closing the month.

The usual freezes on a small desk are short and predictable. For finance systems, they cover the last two working days of the month and the first one. Other usual freezes cover the day before and the day of the payroll run; year-end; the peak trading fortnight; exam weeks; and the audit week. The week the only senior technician is away is a freeze for everything. Enter the recurring ones for the whole year as soon as the dates are known, and the review will never again have to remember them.

The argument you will hear is "it's a small change". The reply is to ask whose Friday night it ruins if it is wrong, and to point at the calendar. A freeze is a decision the desk made in daylight so that it does not have to be remade at 17:45 by someone who is tired and confident. Keep freezes short and named, though. A desk that is frozen half the year has a scheduling problem dressed up as caution. The review is the place to say so.

The Questions to Ask of Each Change

The reviewer asks five questions of each normal change, in order, and expects the answers to be on the record already. If they are, the ninety seconds is spent confirming them. If they are not, the record goes back and the change waits. The questions are deliberately plain. They are the five risk questions from What Needs Review and What Does Not, turned into things one colleague can ask another across a screen.

• What exactly changes, before and after, in one sentence?
• Who notices if it goes wrong, and have they been told the window?
• What is the rollback, how long does it take, and has it been tried?
• Is anything else on the calendar touching this system within a day either side?
• Is anyone this change depends on away that day?

The third question is the one that sends records back most often, and the fifth is the one most often forgotten. A record that answers all five is read in under a minute. The seven fields that hold the answers are laid out in The One-Page Change Record. A desk whose records follow that shape finds the review gets shorter every month, because the questions are being answered before they are asked.

Running It With Two People, or One

With two people the review is the same agenda over coffee, five minutes. The other person is the reviewer for everything. The calendar matters more with two, not less, because with two there is no slack: every people conflict is a conflict with the only other person. The outcome lines still get read, the emergencies still get asked their three questions, and the pre-approved list still gets its quarterly prune, in the same five minutes.

With one person the review is the record, read aloud by its own author the morning after it was written and before the change is made, with the calendar open. Reading your own record aloud, alone, feels faintly ridiculous. It also works, because the rollback line sounds different spoken than it looked typed, and "switch it back" is embarrassing to say out loud. Once a month, borrow a reviewer for fifteen minutes: the manager, a colleague from another team, the supplier's engineer, anyone who will ask "to what?". The case for writing things down as the solo administrator's second person is made in Documentation as Your Second Person. The change record is the most valuable page in that set.

Keeping It to Fifteen

Six rules keep the review at fifteen minutes, and all six will be tested in the first month. Nothing is reviewed without a written record. No design discussions; park them with a name and a date. The pre-approved list is not relitigated weekly; it has a quarterly slot. Someone is timekeeper, and it rotates. The review starts on time without waiting for anyone. And it ends at fifteen even when the list is not finished, because a review that runs over once will run over always.

What makes a review grow is never the changes. It is the extra attendee who wants context, the status update that someone thought would be useful, the slide that explains the change the record already explained, and the words "while we're all here". A review that reaches thirty minutes will be skipped by half the room within a quarter. A review that is skipped is a desk back to asking what changed on Tuesday. Fifteen minutes is not a target. It is the ceiling, and the ceiling is the whole reason people come.

A Short War Story: The Rent Run at Ashgrove Housing

Ashgrove Housing's desk of four had no change review. So when Greta booked a storage-controller firmware update for a Friday at 19:00, there was nowhere for anyone to mention the monthly rent run. That run collects direct debits for three thousand one hundred tenancies and started at 20:00 from a server on that storage. The controller rebooted twice during the batch, and the batch half-completed. By Saturday morning some tenants had been debited twice, some not at all, and the finance system's own log could not say which. Finance spent the following week on refunds and letters, the housing manager spent a morning explaining it to the board, and a complaint went to the regulator. The desk added the rent run to a new change calendar the next Monday, as a two-day freeze on finance systems every month for the next year. The desk started a Thursday review the same week. The lesson Ashgrove wrote on the calendar's first entry was that the desk cannot avoid a date it cannot see. The calendar's job is to hold the business's dates as well as the desk's.

The Review Agenda

The agenda below is the fifteen minutes on one page. Print it, pin it beside the screen where the review happens, and tick the boxes as you go. The timekeeper reads the minute marks aloud. The outputs at the bottom are what exists after the review that did not exist before. If any of the three is blank the review has not finished. Change the day, the time and the names, and leave the minute marks alone.

WEEKLY CHANGE REVIEW — FIFTEEN MINUTES
Desk: ______________   Day and time: ______day ____:____   Timekeeper: ________
Present: __________________________________   Outside guest (if any): ________

MINUTES 0-2   LAST WEEK'S OUTCOMES
  [ ] Each change due last week read by its outcome line
      done ____   rolled back ____   partial ____   no outcome line ____
  [ ] One sentence on each rollback or partial: ____________________
  [ ] Records with no outcome line: owner asked, due today

MINUTES 2-10  THIS WEEK'S NORMAL CHANGES (ninety seconds each)
  For each: doer reads what, when, rollback; room asks the five questions
  [ ] CHG ______  ______________________  window agreed [ ]  back for work [ ]
  [ ] CHG ______  ______________________  window agreed [ ]  back for work [ ]
  [ ] CHG ______  ______________________  window agreed [ ]  back for work [ ]
  [ ] CHG ______  ______________________  window agreed [ ]  back for work [ ]
  [ ] CHG ______  ______________________  window agreed [ ]  back for work [ ]
  Parked for a separate conversation: ____________  owner ________  by ________

MINUTES 10-13 THE CALENDAR, TWO WEEKS AHEAD
  [ ] Two changes on one system within a day of each other: ____________
  [ ] Any change inside a freeze period: ____________
  [ ] Any change whose doer, second person or rollback expert is away: ____
  [ ] Supplier maintenance windows entered: ____________
  [ ] Freeze periods to add or extend: ____________

MINUTES 13-15 EMERGENCIES AND THE LIST
  Emergencies since last review: ____
  [ ] For each: was it one? did the fix hold? follow-up ticket number: ______
  [ ] Pre-approved list: entries to add ______  entries to strike ______

OUTPUTS (all three before the review ends)
  [ ] Calendar updated with every window agreed above
  [ ] Each record marked "read at the review on ________"
  [ ] One line posted to the team chat: "Review done: __ approved, __ back,
      __ moved, __ emergencies, next review ________"

Tollgate's Thursday has run every week since, including the week Rosa was away and Theo chaired it from his phone in a car park. It has never reached twenty minutes. The month-end valuation is on the calendar as a freeze on the file server for three days every month. Wen comes on the first Thursday to check the dates. The storage and the file server have not been touched in the same window since. The review's longest-standing output is a sentence in the team chat every Thursday at 09:15 that says how many changes were read. The desk has come to find it reassuring in roughly the way a lighthouse is reassuring: nothing happening is the news.

Frequently Asked Questions