The change management process

The thinking move: governance is a loop, not a folder

Asked how they manage change, most candidates describe a branch and a pull request. That answer is not wrong, it is at the wrong altitude. The exam is asking about a governance loop that exists whether or not a version control system does: who may ask for a change, who evaluates it, who decides, what the decision is written down as, who is allowed to touch the item afterwards, and how anyone downstream finds out. Tools automate parts of that loop. They do not constitute it.

The loop

A change request is submitted by anyone — a user, a developer, a support engineer. It is evaluated on four counts: is the change technically sound, what else might it disturb, what does it do to the other configuration objects and to the functions that depend on them, and what will it cost. The result of that evaluation is written up as a change report. The report goes to a change control authority (CCA) — sometimes a change control board, sometimes one named person on a small project — which makes the final call on the change's status and priority. For each approved change an engineering change order (ECO) is generated: it spells out exactly what is being changed, what boundaries the work has to stay inside, and how the result will be checked and signed off. Only then is the object checked out, changed, reviewed and checked in, producing the next version.

Two controls sit inside that check-out/check-in cycle and they are commonly confused. Access control governs who is permitted to obtain and modify a particular configuration object. Synchronization control ensures that parallel changes made by two different people do not overwrite one another. They answer different questions — permission versus serialisation — and naming both, correctly, is worth a mark.

The asymmetry again, and the two closing tasks

The loop above is what applies after an item is baselined. Before that, only informal change control applies: the author of the SCI makes whatever changes the work requires, provided they do not reach outside their scope. Once a technical review approves the item and a baseline exists, project-level change control begins — the developer needs the project manager's approval for a local change, or the CCA's if the change touches other objects. Being able to state that switch, and to say why it exists, is the difference between describing a process and understanding one.

The loop is closed by two tasks that answer the question control mechanisms cannot: was it actually done properly? A configuration audit complements the technical review. The review asks whether the modified object is technically correct; the audit asks whether the change specified in the ECO was the change made, whether a review was held, whether the process and standards were followed, whether the change was highlighted and attributed in the item, whether SCM procedures for recording and reporting were followed, and whether every related SCI was updated too. Configuration status reporting then answers four questions for everyone downstream: what happened, who did it, when did it happen, and what else will be affected.

Worked example — the BorrowBox token change, governed

Support files a request: extend the one-time locker token from 120 to 300 seconds because members with gloves in winter are timing out. Evaluation finds the technical merit (a real, measurable failure rate at the locker), the side effects (a longer window is a longer replay window — a security regression), the impact (design model, app source, locker firmware, two test specs), and the cost (a firmware release to 40 lockers, which is a technician visit for the 6 that are offline). BorrowBox's CCA is two people: the product owner and the security lead. They approve, with a constraint: 300 seconds only if the token is additionally bound to a single locker ID. That constraint goes into the ECO, which is the reason the constraint survives to the person who writes the code three weeks later.

The app and firmware items are checked out — access control means only the two engineers on the locker component can, and synchronization control means the second one's check-in cannot silently overwrite the first. The change is reviewed and checked in. The audit then catches what everybody had forgotten: the operations runbook is an SCI too, and it still tells the on-call engineer that a token is valid for two minutes. That is exactly the class of miss an audit exists for, and no branch protection rule would have found it.