Risk register in one silo, change control in another
Meridian Retail is deploying a new point-of-sale platform to 240 stores under Project Atlas. The project risk register lists 40 risks, but the deployment team has begun using an unapproved 'standard change' template to push store-level configuration changes without CAB review, arguing that the weekly CAB has a 60-item agenda and an eight-day lead time. Last month an emergency change to the payment terminal configuration caused a four-hour outage in 31 stores. Problem management has not been engaged because the project manager says incidents are 'operations' business'. Release and deployment are managed by a different team that receives build notes by email. The project manager believes risk management is a project responsibility and change enablement belongs to service management. The steering committee asks why the project is 'green' when store staff report repeated payment failures and a growing backlog of known errors. Atlas has six weeks before peak season.
1. Diagnose the practice integration failures. Which ITIL 4 practices are interacting, and what is the consequence of treating them as silos?
Read the worked answer
The case shows project management, risk management, change enablement, release management, deployment management, incident management, problem management and service configuration interacting badly. ITIL 4 practices are sets of organisational resources designed for value co-creation; they overlap in real work and cannot be assigned to separate tribes without losing information at the boundaries.
The unapproved standard change template is the clearest failure. Standard changes are pre-authorised only when the change model defines them, their risk and their conditions. A team inventing a template to avoid CAB is not using change enablement; it is circumventing it. That creates unauthorized change risk and explains the emergency change and outage. Because problem management is excluded, repeated payment failures are handled as individual incidents and known errors accumulate without root-cause action. The project risk register therefore misses operational evidence that should change project priorities. Release and deployment are split by email, so build content, configuration and store readiness can diverge.
The consequence is a false green status: project measures show progress, while service measures show failure. Risk is being transferred to stores rather than managed. The steering committee should see one integrated risk and readiness picture, not a project register plus an operational incident backlog.
2. The PM says risk management is a project responsibility and change enablement belongs to service management. Evaluate this position.
Read the worked answer
The position is a false dichotomy and it is unsafe in this context. Project management certainly includes risk management, but that does not mean project risk ends at the project boundary. A point-of-sale rollout changes live services and configurations in 240 stores; those changes are precisely where project risk becomes operational risk. Change enablement applies to changes, whoever originates them, and it should be proportionate to risk. The project must comply with the organisation's change model and should help design a model that fits frequent store configuration.
Likewise, service management does not own risk in isolation. Incident and problem data are evidence for the project risk register and backlog. If problem management identifies a recurring terminal configuration defect, the project should reassess release readiness and residual risk.
The PM should reframe the relationship: project management provides the plan, business case, risk and stakeholder coordination; change enablement provides risk-based authorisation and change models; deployment and release provide controlled movement into live use; problem management provides root-cause learning. The PM does not need to own every practice, but the project must integrate with them. Otherwise 'not my responsibility' becomes an unmanaged interface, which is exactly what the outage exposed.
3. Recommend immediate and structural actions for the six weeks before peak season.
Read the worked answer
Immediate actions should stabilise risk, not merely speed up approvals. First, suspend the unapproved standard change template and triage any changes made under it; identify which store configurations need retrospective review or remediation. Second, establish a named change authority for store configuration with clear thresholds and an emergency route, so urgency does not require bypassing control. Third, convene a joint risk review with project, operations, change, deployment and problem management; merge the top operational risks into the project risk register and assign owners. Fourth, engage problem management on the payment failures and make known errors visible to release and deployment planning. Fifth, replace email build notes with a single release and deployment record covering versions, configuration, store readiness and rollback.
Structural actions should prevent recurrence. Redesign the change model so standard changes are genuinely low-risk, defined and auditable; route CAB items by risk and impact rather than volume; and set change lead times that reflect peak-season constraints. Integrate risk registers at agreed review points. Define release and deployment handoffs and acceptance criteria. Use incident and problem trends as project readiness measures. For the six weeks, adopt a daily operational readiness huddle and a freeze window for non-essential change as peak season approaches. The aim is to make the safe path the fast path, not to add another committee.