The Insurer's Change-Related Incidents
An insurer deploys four releases a week across 60 applications. Post-incident analysis shows 62% of severity-one incidents are change-related, emergency changes are 18% of all changes, and the problem backlog stands at 240. Access requests through the request portal average nine days against a two-day target. A release altered entitlement logic for policyholders; monitoring raised an event, but the incident record had no link to the change record or to the affected configuration items. Six thousand customers could not retrieve documents for five hours. The change advisory board meets weekly and treats emergency changes as a separate paper process. The CIO wants to know whether the answer is more change controls, a faster release process, or a different operating model. You are asked to trace the failure across the IT4IT value streams and recommend where decision rights should sit.
1. Trace the failure across the four value streams and identify the earliest point at which an IT4IT operating model would have surfaced it. Be explicit about which link was missing.
Read the worked answer
The policy change originated as demand in S2P, where the portfolio should have recorded the intended outcome and the affected service and consumer segment. R2D turned it into a requirement and a release; at that point the release package should have carried the requirement, the service and the configuration items it would change, plus test evidence for entitlement rules. R2F holds the subscription and entitlement records for the 6,000 policyholders, so it could have identified the affected population. D2C detected the event and raised the incident.
The earliest surfacing point is the R2D release gate: a release that changes entitlement logic cannot be assessed for impact unless its deployment record is linked to the service, the CIs and the entitlement rules it modifies. If that link exists, D2C can immediately scope the incident to the change and the affected population. If it does not, D2C detects a symptom with no causal path.
The missing links are release-to-CI, change-to-CI, incident-to-change and service-to-service contract. The failure is therefore not a monitoring failure; it is a backbone failure at the R2D-D2C boundary.
2. Should emergency changes be owned by D2C or R2D? Defend the split of decision rights and execution.
Read the worked answer
Separate the decision to change from the act of changing. IT4IT places change control in Detect to Correct: it evaluates impact, risk and urgency, authorises or rejects the change, and coordinates recovery. That is where emergency change decision rights belong, because the trigger is an event or incident and the objective is restoring service. R2D owns the build, test and deployment capability that implements the change, including the release and deployment records.
The failure mode in the scenario is not that D2C owns emergency change; it is that emergency change became a paper process outside both value streams. A defensible split is: D2C authorises the emergency change and records the risk acceptance; R2D executes through the same pipeline with an abbreviated but not absent test and deployment record; R2F handles pre-approved standard changes that are low risk and well understood. If R2D were made the owner of emergency change, impact assessment would be separated from the incident context and recovery would slow. If D2C executed changes itself, release integrity and configuration control would fragment. The boundary is decision versus execution, with the change record as the shared object.
3. Which two data relationships would most reduce the 62% change-related incident rate, and what would each change in practice?
Read the worked answer
First, change-to-configuration item, carried from the release record into the change record. Without it, impact analysis is based on team memory and incident diagnosis cannot name the changed component. In practice it forces R2D to publish a deployment record with CI identifiers and forces D2C to use it, which turns the weekly CAB from a queue into a risk conversation about known components.
Second, incident-to-change, with problem-to-change for recurring causes. This allows severity-one incidents to be attributed to a change within minutes and allows the problem backlog to be prioritised by change-related recurrence rather than by age. In practice it creates a feedback loop: repeat change-related incidents become a release quality signal in R2D, not just a service desk metric.
A third candidate, service contract to service and CI, would improve customer impact assessment, but it would not by itself reduce the change-related rate. The first two change behaviour because they connect the release decision to the operational consequence.