Change Advisory Board Bottleneck
A bank's change-request process has five stages: request, triage, risk assessment, change advisory board (CAB) review, and implementation. It handles about 480 changes per quarter; 40% are emergency changes. Average lead time is 23 days. Approximate elapsed time is 6 days waiting for triage, 4 days of risk assessment, 7 days waiting for the weekly CAB, 2 days of implementation, and 4 days of rework after failed changes. Two CAB representatives review every change, although 70% are low-risk. Failed changes run at 12%, and unauthorized changes at 18%. The CIO wants faster flow but will not accept weaker control. The change manager proposes adding two more CAB reviewers and keeping the weekly meeting. You are asked to diagnose the process and recommend a redesign that protects control.
1. Calculate the approximate lead-time breakdown and identify the main constraint. What is the risk of simply adding two CAB reviewers while keeping the weekly meeting?
Read the worked answer
Elapsed components: triage wait 6 + risk assessment 4 + CAB wait 7 + implementation 2 + rework 4 = 23 days. The largest single delay is CAB wait at 7 days, followed by triage wait at 6; risk assessment and rework add control and failure cost. Adding two reviewers may increase review capacity, but if the CAB still meets weekly and batches all changes, average wait remains roughly half the meeting interval for changes that miss the cutoff-about 3.5 days at best-and many low-risk changes will still queue. Worse, more reviewers can increase inconsistency and handoffs without reducing the batch. The 40% emergency rate suggests the normal path is too slow, pushing work into emergency channels. The constraint is the scheduling and segmentation policy, not just reviewer headcount. First separate low-risk standard changes from high-risk ones and delegate approval.
2. Recommend a risk-based segmentation and governance design that speeds flow without weakening control.
Read the worked answer
Create three classes. Standard/low-risk: pre-approved, automated checks, no CAB; post-implementation review and sampling. Normal: risk assessment, delegated approval by domain owner or CAB subcommittee, with a service-level target of two business days. Emergency: expedited path with an incident manager and retrospective CAB review. Use explicit risk criteria-customer impact, regulatory, financial, security, reversibility-and automate evidence collection. The full CAB should review only high-risk and cross-domain changes, not 480 per quarter. Keep separation of duties: the person implementing does not approve; emergency changes require a second authorization. Publish a change calendar and test policy. Expected effect: low-risk changes bypass the weekly batch; CAB capacity focuses on risk. Guardrails: unauthorized changes should be detected by automated reconciliation of deployed versus approved changes, and failed changes reviewed for root cause.
3. What metrics would you use to monitor whether the redesign improves flow without increasing change risk?
Read the worked answer
Flow metrics: median and 90th-percentile lead time by change class, percent of changes through the standard path, CAB queue time, and batch size. Risk metrics: failed-change rate, emergency change rate, unauthorized change rate, rollback rate, and control-test exceptions. Quality: first-time-right risk assessment, completeness of evidence, and repeat incidents from changes. Balance metrics: CAB review hours per change, percentage of low-risk changes reviewed by CAB, and post-implementation review completion. Use a baseline of 23-day lead time, 12% failed, 18% unauthorized, and 40% emergency. Track trends weekly with control limits; a drop in lead time accompanied by rising unauthorized or failed changes signals that control is being bypassed. This keeps the CIO's two goals-speed and control-visible in the same dashboard.