Change advisory board: what it should review, and what it should not

A change advisory board is the group that reviews and authorises changes to production systems. In its classic form it meets weekly, works through a list of proposed changes, and approves, defers or rejects each one. Almost every organisation past a certain size has one, and a large share of them are dissatisfied with it.

The dissatisfaction usually comes from scope. A board that tries to assess whether each change is technically correct duplicates the review the engineering team already did, adds days of latency, and has no realistic way of doing it well — the people in the room rarely know each system deeply. A board that instead asks about risk, timing and collisions is doing something the engineering team genuinely cannot do for itself.

What a change advisory board is well placed to assess

• Collisions: two changes to related systems in the same window, or a change during another team’s critical event.
• Timing: whether the proposed window is sensible given business activity, staffing and what else is running.
• Blast radius and rollback: whether the change can be undone, and whether anyone has confirmed that.
• Communication: who needs to know, and whether customers or support teams have been told.
• Whether the change is correctly classified — standard, normal or emergency.
• Patterns across changes: the same system failing repeatedly, or the same team routinely requesting emergency status.

Classify changes so most never reach the board

• Standard changes — pre-approved, low risk, well-rehearsed, executed without individual authorisation. This category should be large and should grow.
• Normal changes — assessed individually, which is what the board exists for.
• Emergency changes — authorised by a smaller group, quickly, and reviewed afterwards rather than beforehand.
• The health of the process is largely the proportion in each bucket. A board reviewing hundreds of routine changes has failed to build the standard-change catalogue.

Watch the emergency route. When normal approval is slow, teams reclassify ordinary work as emergency to bypass it, and the board stops seeing the changes it most needs to see. A rising emergency share is a signal about the board rather than about the systems.

Latency is a real cost

A weekly board adds up to a week of delay to every normal change, which pushes teams towards larger batched releases — and larger releases fail more often and are harder to diagnose. Research on delivery performance has consistently found that heavyweight approval processes correlate with worse outcomes, not better ones. That is not an argument for abolishing oversight; it is an argument for making the standard-change path the default and reserving individual review for changes that genuinely warrant it.

Keeping the record

What is worth retaining is not the minutes but the decisions: what was approved, by whom, for which window, with what rollback, and what actually happened. Ettex Records holds the change record per system with the outcome recorded against the approval, Ettex Sheets tracks the mix of standard, normal and emergency changes over time so the trend is visible, and the review after something goes wrong is covered in incident postmortem. The document proposing the change is covered in change request.

Being direct: this is records and spreadsheets, not an ITSM platform. Workflow, approvals and CMDB integration belong in dedicated tooling; what this covers is what the board should be for and what to keep afterwards.