Post-Merger Operating Model: Reconciling ITIL and DevOps Governance
Two banks have merged. Bank A is ITIL-heavy: five change advisory boards, a 12-day average change lead time, and strong evidence trails. Bank B is DevOps-oriented: 40 deployments a day, small teams, and weaker change evidence. The combined IT group has 2,500 staff and 14 critical services. A regulator has set a nine-month deadline for integrated controls. There is a backlog of 400 changes, incident MTTR is six hours, and an audit has already flagged three critical changes that went live without approval. Bank A leaders want one change process; Bank B leaders say that will stop delivery. The CIO asks how the VeriSM operating model can reconcile governance and management without defaulting to either bureaucracy or uncontrolled speed. A decision is needed before the next regulatory checkpoint.
1. Using the VeriSM operating model, diagnose the governance and management conflict and recommend an integrated design.
Read the worked answer
The conflict is framed as ITIL versus DevOps, but VeriSM treats governance and management as linked layers: governance sets direction and risk appetite, while management practices deliver within them. Bank A's five CABs are a management practice being used as a substitute for governance; Bank B's speed is valuable but lacks evidence for critical services. An integrated design should define risk tiers by service criticality and change impact. Low-risk standard changes can be pre-approved and automated; critical changes require evidence and accountable approval. Create one change policy owned by governance, but let teams choose flow methods. Establish a change advisory function that focuses on risk and improvement, not batch approval. Define decision rights for emergency changes, and make evidence automatic where possible. Measures should include change lead time, percentage of standard changes, audit exceptions, and MTTR. This preserves Bank B's delivery speed for low-risk work while restoring the evidence Bank A and the regulator need for critical services.
2. What immediate actions and measures would you take in the first 90 days to reduce the 400-change backlog while preserving audit compliance?
Read the worked answer
First, classify the backlog by risk and service criticality; many changes are likely low-risk and can be pre-approved under a standard-change model. Second, map the change value stream to find waiting time, not just approval time; five CABs may be creating queues. Replace routine CAB review with automated evidence checks and a smaller advisory forum for high-risk changes. Third, define emergency change criteria and require retrospective evidence within 24 hours. Fourth, publish a single change calendar and a visible exception log so audit can see control, not just paperwork. Measures: backlog age and size, average lead time, percentage of changes handled as standard, audit exceptions, failed changes, and MTTR. Target a measurable reduction in backlog within 90 days without reducing evidence for critical services. If audit exceptions rise, tighten the risk tier rather than re-adding layers of approval.