Regulatory Lead Time at NorthBank
NorthBank's mobile payments group employs 240 engineers across 12 teams and delivers about 45 features per quarter. Every feature follows the same path: intake, business case, architecture review, development, system test, user acceptance test, weekly change advisory board (CAB), and production. End-to-end lead time averages 63 working days. Of that, 19 days are spent waiting for one of two shared test environments used by all 12 teams; the CAB rejects 18% of changes on first review for missing test evidence, adding another 6 days; and 30% of features are reworked after UAT because acceptance criteria were unclear. The release manager coordinates roughly 40 production deployments a month. A new payments regulation now requires certain customer-facing changes to reach production within 15 working days, and the board has asked for a future-state value stream that improves flow without weakening financial controls or audit evidence.
1. Using the scenario, identify the main constraints and waste in the current value stream. What specific data would you collect, and how would you distinguish a capacity constraint from a policy constraint?
Read the worked answer
Start by walking the actual work, not the organisation chart. Build a value stream map for one feature type, such as a regulatory payment change, with stage times, wait times and rework loops. From the data given, the largest elapsed-time contributors are the shared test-environment wait (19 days), CAB rework (6 days) and UAT rework (30% of features).
Classify each cause. Test-environment contention is likely a capacity constraint: two environments serve 12 teams. The 18% CAB rejection may be a policy and quality constraint: entry criteria and evidence standards are unclear or too manual. UAT rework is a quality-at-source problem: acceptance criteria were not agreed early enough.
To distinguish capacity from policy, test options. If adding an environment or using ephemeral environments cuts the wait, capacity was binding. If changing entry criteria or delegated approval cuts rejections without extra capacity, policy was binding. Collect timestamps per stage, queue time, touch time, percent complete and accurate, rework loops, CAB rejection reasons, environment booking logs and deployment outcomes. Stratify by change risk and type. This matters because optimising development alone will not meet the 15-day target when most delay sits outside development.
2. Propose a future-state value stream. Name the changes to stages, handoffs and controls, and explain how each change addresses a constraint while preserving audit and risk requirements.
Read the worked answer
Segment the value stream by risk and change type instead of forcing all 45 features through one path. Low-risk, well-understood changes should use a standard change model with pre-approved, automated evidence. High-risk changes keep architecture review and stronger change enablement scrutiny.
Replace the two shared test environments with self-service, ephemeral environments created by the pipeline, and make test evidence a pipeline output rather than a manually assembled document. This attacks both the 19-day queue and the missing-evidence rejections. Move acceptance criteria and examples to intake, and validate them iteratively before UAT. Introduce a delegated change approval forum with clear entry criteria and automated audit evidence, meeting more often or on demand. Reduce handoffs by making product teams accountable from build through run, with a support representative embedded in the team.
Each change targets a quantified constraint. Controls are not removed; evidence moves into automation. Risks include weaker segregation of duties and poor environment discipline, so add policy-as-code, audit logs, role separation and periodic sampling. Treat this as design and transition plus continual improvement, not merely a tool purchase.
3. How would you validate that the future-state value stream actually works, and which measures would you use to show improvement?
Read the worked answer
Run a time-boxed pilot on one regulated feature type, using the same definitions as the baseline. Compare end-to-end lead time (target of 15 working days or less), flow efficiency, test-environment wait time, first-pass change approval rate, change failure rate, UAT rework percentage, deployment frequency and audit findings.
Use a before-and-after comparison and, if possible, a control group of features outside the pilot. Check guardrails as well as speed: no rise in failed changes, incidents or audit exceptions. Test the future state against both a routine low-risk change and a high-risk regulatory change; a model that only works for low-risk work would not satisfy the board.
Review weekly with the value-stream team and adjust. If lead time falls but change failure rate rises, the constraint has moved or controls have been weakened, so stop and diagnose rather than declare success. Report flow, quality and risk together.