Brenmoor Retail: a change pipeline nobody trusts

Diagnosis - five distinct faults, not one.

1. Decision rights are allocated by cost and by hierarchy, not by risk and impact. A £50k threshold makes the CIO a bottleneck on trivial spend while the e-commerce director self-approves changes that can take down the storefront.
2. Self-approval where segregation matters. The group that builds the change also authorises it; there is no independent check on the highest customer-impact area.
3. One board, one queue. Fast, low-risk changes and complex, high-risk changes wait in the same 190-item backlog. Median wait of six weeks for routine work drives workarounds, which is why 31% of changes are emergencies - the emergency channel is the rational response to a slow standard channel.
4. No risk classification. Without a model for what a change touches (payment path, store trading hours, customer data), no one can route it correctly.
5. No definition of value or baseline, so prioritisation is political and the improvement register cannot be triaged.

Reallocation:

• Adopt a change-enablement model: pre-authorised standard changes (low risk, repeatable, tested) executed without CAB review; normal changes assessed against a defined risk/criticality model; significant changes to a small, senior board. Emergency remains, but is measured and trended as a defect in the process.
• Move approval authority to the owner of the risk, not the owner of the budget: the e-commerce director should not approve changes to their own domain's production path; a peer or platform owner with an independent check should.
• Cap the number of items in flight and publish the WIP limit; a 190-item queue is a symptom of unrestricted intake, not of insufficient throughput.
• Define value in measurable terms with a baseline before prioritising - otherwise the reallocation just moves the argument.

The principle: a process with no feedback cannot improve; it only escalates. Brenmoor's current metrics are outcomes of failure (outage count), not signals of drift, so corrective action always arrives after the customer has been affected.

Close three loops:

1. Operational loop (per change). Smallest safe change size, with verification immediately after deployment and automated rollback. Purpose: reduce the blast radius so an error costs minutes, not a peak trading day. Measure: change success rate, failed-change recovery time.
2. Tactical loop (weekly). Review of emergency proportion, queue age by risk class, and rejected/returned changes. Purpose: detect whether the routing model is wrong. A rising emergency share is a signal that standard changes are misclassified, not that engineers are careless.
3. Strategic loop (quarterly). Whether the change portfolio is delivering the outcomes the business asked for. Measure: proportion of capacity consumed by run/keep-the-lights-on versus planned value; realised benefit against the stated hypothesis for the top few initiatives.

First measures - deliberately few: lead time from approval to production by risk class; percentage of changes classified standard/normal/emergency; change success rate and mean recovery time; unplanned customer-impacting incidents per release; and progress of the improvement register (items closed, and - critically - items validated as having improved a measure).

Why validation matters: 240 open improvement items with 12 implemented tells you items are recorded, not that anything changed. Improvement must be linked to a before/after measure or it is administration. Ensure someone owns each loop and has authority to act on what it shows; a loop with no authority is reporting.

Do - buy down risk, in order of leverage:

1. Freeze scope, not change. A change freeze for peak looks prudent and reliably fails, because the business keeps needing changes and simply raises them as emergencies - Brenmoor already runs at 31% emergency. Instead, cut the peak release to the minimum set of changes with a validated rollback path, and route everything else to a post-peak window with a published date.
2. Rehearse failure, not just success. Test rollback and degraded-mode behaviour under peak-like load. Two outages in four releases suggests the failure mode was untested, not that the release was unlucky.
3. Separate deploy from release. Where possible, deliver to production behind feature flags so exposure is a business decision taken in trading hours, reversible in seconds.
4. Protect the trading path explicitly. Classify the checkout and payment path as a high-criticality component with a named owner, independent approval and a stricter readiness bar.
5. Publish readiness criteria agreed with store operations and e-commerce before the freeze: what must be true to release.

Do not:

• Do not respond by adding more approval layers. Gate count does not correlate with safety; the current self-approval problem shows layers can coexist with high risk.
• Do not ban emergency changes. They are the symptom of an unworkable standard path; banning them drives the work underground.
• Do not attempt the full governance redesign before peak. Sequence: stabilise the peak release first, then reallocate decision rights - otherwise the reorganisation becomes the outage.

Judgement: the readiness bar should be set from evidence (what the two failures had in common), not uniformly. If both outages trace to one component or one team's testing gap, targeted action beats a firm-wide clampdown.