Change Advisory Board Lab

A browser-based training lab where you chair the change advisory board of a fictional freight forwarder. Over three CAB decisions you choose the route, the evidence, the conditions, the calendar, the communications and the review, and see a seeded outcome of what happened. It trains governance judgement, not tool syntax.

In ITIL change enablement terms, the change advisory board reviews and advises on normal changes that need case-by-case assessment, and a faster emergency group handles urgent ones. A good board asks for evidence, removes standard changes from its agenda, sequences work on the calendar, attaches conditions to approvals and reviews outcomes. It is not a vote on every request.

It is a list of pre-authorised, low-risk, repeatable changes, each with a written procedure and a track record. Items that match an entry skip the board, such as a monthly patch ring in the first decision. That frees the board to spend its hour on the items that need judgement, and sending a catalogue change through the full board is over-governing.

No. An emergency change is needed to stop active or imminent harm, such as exploitation in the wild of an internet-facing appliance. A requester's deadline, a demo or a loud email is urgency, not an emergency. In the queue decision, R4 is marked urgent but cites no exploitation and can wait.

Whether it met the emergency criteria, what was tested and when, what was left behind, who was told, and what the numbers say. In the lab the emergency was valid, but a temporary firewall exception stayed open, the rollback was never tested and nobody did the post-change checks. The retrospective closes the leftover, updates the KPIs and keeps the shortcut from becoming the habit.

Change failure rate (the share of changes that cause a failure or need a rollback), emergency share (how many changes use the emergency path), standard share, and collisions caught on the calendar. They are read from the register, and the point is to look for patterns such as a rising emergency share, not to hit a target.

With facts rather than volume: overlay the changes on the dependency map and the calendar, put a hard expiry first with margin, never put changes that share a component on the same night, and keep each change's rollback separate. In the lab the certificate rollover goes first, the firewall clean-up waits until it is verified, and the EDR change starts as a pilot.

Each decision hides a few risks, such as two items colliding, a deferred item done anyway or an exception left open. The seed fixes the dice. Evidence rules, conditions, calendars and attendees that address a risk make it much less likely to fire, and a good decision log or review limits the damage if it does. The same seed, level and plan always give the same outcome.

Rookie shows a hint at each step and a "watch for" list of hidden problems, and has the lowest chance that an unmitigated risk fires. Pro hides the hints, but a good evidence rule reveals a hidden problem as you choose it. Elite hides everything until the outcome and raises the chance that an unmitigated risk fires.

A Markdown record per decision, with route, risk, who sat, evidence, conditions, calendar, communications, review, the simulated outcome and the process findings, and a CSV register of all three. Downloading and copying documents is Pro. You can read the same records on the debrief page.

No. Aldermoor Freight, its people, systems, calendar and the aldermoor.example domain are invented, and every outcome is simulated in your browser. The lab reads each CAB decision through the same steps as a single change, so the step names are a close fit rather than an exact match.