A 412-Item Register and a CIO in a Hurry at MetroRail
MetroRail's IT director has inherited a continual improvement register with 412 open items and an average age of 14 months. Teams log ideas after incidents; there is no agreed 'where we are now' baseline, no expected outcome or measure recorded, and 60% of entries read simply 'fix this bug'. The register is reviewed quarterly by a change advisory board that approves or rejects items in five-minute slots. Last year 38 items were closed as complete, but no one can show a measurable change in any service. A newly appointed continual improvement manager proposes formally adopting the ITIL 4 continual improvement model, starting with a vision workshop and then working through 'where are we now' and 'where do we want to be'. The CIO wants a faster route: 'just prioritise the top 20 items and get on with it; we cannot afford workshops.' The improvement manager has one part-time analyst and no budget.
1. Assess which steps of the ITIL 4 continual improvement model are weakest in MetroRail's current approach, and explain the consequences.
Read the worked answer
The weakest steps are 2 (where are we now), 3 (where do we want to be), 4 (how do we get there) and 6 (did we get there). Step 1 is implicit at best - no one has articulated what improvement is for, or for which services and customers. Step 5 (take action) is the only step functioning, and it is why 38 items could be 'closed' without evidence.
Consequences follow directly. Without a baseline, no one can state the size of a problem or prove a change. Without an expected outcome, prioritisation collapses into opinion, which is what five-minute CAB slots represent. Without an evaluation step, closure means 'work done', not 'value delivered', so the organisation cannot learn which interventions work and staff learn that the register is a filing cabinet. Skipping step 7 (keep momentum) explains the 14-month average age: there is no visible success to sustain interest. The model is iterative rather than strictly linear, but omitting the diagnostic and evaluative steps removes the feedback loop that makes it continual improvement rather than a task list.
2. The CI manager proposes starting with a vision workshop; the CIO wants to start with the top 20 items. Give your recommendation and the reasoning behind it.
Read the worked answer
The choice is a false dichotomy; both positions are partly right. A short vision statement matters because 'improvement' without a scope will keep the register generic: one page naming the services, customers and outcomes in scope, agreed with the IT director, is enough. The baseline matters more, because it is the missing capability, but it does not require a lengthy study: select five to ten measures already available (incident volume and resolution time, change failure, availability, cost per ticket, customer satisfaction) and establish current values per service.
The practical route is a two-to-three-week sprint: vision and scope in a half-day workshop, baseline from existing data, then score the top 20 items against expected outcome, effort and risk. That respects start where you are and keep it simple and practical, avoids the analysis paralysis the CIO fears, and gives prioritisation a defensible basis. What must not happen is prioritising the top 20 by who shouts loudest - that repeats the existing failure with better project management.
3. Describe what the improvement register should record and who should own it.
Read the worked answer
The register is the practice's core artefact and should be designed for decision-making and learning, not storage. Minimum fields: unique ID; description of the problem or opportunity; affected service, customer and value stream; baseline ('where we are now'); desired outcome with a measure and target; expected benefit and cost or effort; risks and dependencies; owner; priority and rationale; target date; status; evaluation date and result; lessons learned; links to related incidents, problems or changes.
Ownership should be separated. The continual improvement manager owns the register's structure, quality and review cadence, and coaches item owners. Each item has a single accountable owner - usually the service or product owner who can make the change happen and is judged on the outcome. Service owners and sponsors own the value judgement; the CI manager does not. The CAB is the wrong forum for prioritisation: it is a change governance body, not a value board. A monthly improvement review, chaired by the IT director with service owners present, should review evidence, not approve tasks, and should retire items that no longer justify attention.