Why Improvement Registers Go Cold

There is always a spreadsheet. Sometimes a Confluence page, occasionally a Jira swim lane named “Service Improvement”, but always a spreadsheet. Asked why service quality has flattened out, I ask for the improvement register and go down it row by row, asking when each entry last changed. The pause before the answer is the finding. The last one held twenty-odd open items, most raised in a burst after an audit, four of them describing the same weakness.

Nobody there was idle or cynical, which is why the obvious reading — insufficient commitment — produces the wrong remedy, another workshop. A cold register is a mechanism failure: the organisation has built the part of continual improvement that collects intentions and none of the parts that convert them into work.

The Register Is Not the Practice

What ITIL 4 asks for, and what most organisations actually install

ITIL 4 made a change that gets missed, twice over. ITIL v3 gave Continual Service Improvement its own lifecycle volume; ITIL 4 recast it as the continual improvement practice — one of the general management practices — and separately as a component of the service value system, with Improve surviving as one of the six value chain activities. The CSI Approach became the continual improvement model.

The framework says improvement belongs everywhere, and ITIL 4 does describe a continual improvement register: an artefact, not the practice. The best writing on measurement remains the seven-step improvement process, v3 heritage that should be cited as such. Version 5 widens the scope and renames the service value system the ITIL Value System, but the continual improvement practice carries over intact, so I use ITIL 4 vocabulary throughout.

• The practice is a loop, not a list — capture, evidence, decide, act, govern, verify; the register is only its front door.
• One question in the model stops everybody — “where are we now?” requires publishing a baseline somebody will later be judged against, which is why the answer is so often a workshop.
• ITIL 4 does not assume one register — individual, team and organisational registers are all permitted, which is the licence to split the list.

The register gets built first because it is the only part you can show an auditor. Everything else is behaviour, capacity and decision-making, none of which photographs well.

Where the Entries Actually Come From

Registers fill in bursts, and nobody reads one before adding to it

Sort a stalled register by date raised and the clustering is unmistakable. An external audit produces a burst of entries, a bad month for a flagship service another, a post-incident review with a senior sponsor three more in an afternoon. Between those events weeks pass with nothing added, because nothing gave anybody the standing to demand an entry.

The register does not hold a ranked view of the organisation’s weaknesses. It holds a chronological record of its embarrassments, weighted by who was in the room.

• Intake is event-driven — findings and bad quarters generate entries, ordinary weeks none, whatever the internal communications ask for.
• Nobody reads before adding — there is a form for logging and no obligation to look first, so the list grows by accretion.
• Duplicates are a diagnostic — four wordings of one weakness means four authors and no reader.

Which makes the register a measurement, though not of what it appears to measure: it records organisational attention rather than cost, so any campaign to fill it harder produces more of the same bias at greater volume. The list is long and unrepresentative, and its length disguises the second half of that sentence.

Nobody Owns What They Cannot Fund

Ownership follows capacity, and the register’s owner controls none of it

Look down the owner column of a stalled register and you will find department names, occasionally something magnificently abstract like “Service Management”. That column records who raised the item, which is authorship rather than accountability. The owner should be whoever controls the capacity, not whoever holds the skills: somebody a level above the engineer, with the engineer as the doer.

The reason is arithmetic. Operational work arrives with a demand signal that has teeth; improvement work arrives as a line in a spreadsheet, and if it slips a week nothing happens. The engineer who works the P1 rather than the register item is making the correct decision. The protected-time argument from proactive problem work transfers intact, and stings harder here: the register is usually owned by the service management lead, the person least able to fund any of it.

• Name somebody who can move a rota — a team name is declinable accountability, and the owner must be able to reassign that engineer’s week without asking permission.
• The register’s owner should own none of its entries — the service management lead holds the list precisely because they cannot fund it, so every entry they also own is an entry with no counterparty.
• Give the improvement a counterparty — an action with a named requester entitled to chase it behaves like operational work; one raised by “the service review” never will.

I disagree, fairly strongly, with framing this as a cultural problem, though the observation underneath it is sound: two organisations with the same tooling, template and constraints will not close at the same rate, which is what keeps the appetite explanation alive. What actually differs, in the pairs I have seen, is narrower — whether anybody able to move a rota has ever been asked to account for an entry that did not move. It is a design variable that happens to be invisible: the cultural reading describes something real, but has mistaken the output for the cause.

Ideas and Actions in the Same List

The intake standard nobody got round to writing

A typical register carries, on adjacent rows, “review our approach to knowledge management” and “add validation to the joiners form, which accepts a resubmission and creates a second account, owned by the identity service owner, closed after three clean months”. The first is a hypothesis with no evidence, no scope and no test. The second is a specification, and a list that cannot tell them apart cannot be estimated, prioritised or governed.

The distinction needs no standard to justify it, only a view of what the register is for when somebody types into it: deciding whether what was written down is a claim that could turn out false. The first cannot be false. No state of affairs would settle it, which is why it can sit on a list for three years without once being wrong. The second can: the duplicate account exists or it does not, and somebody could go and look. Everything downstream hangs on that, because a claim nobody can check cannot be sized, ranked or honestly closed.

• It must be capable of being wrong — an entry no evidence could contradict is a subject heading, not a candidate for work.
• It must name who is worse off — a weakness with no identifiable sufferer loses every argument it enters.
• It must describe the present, not the remedy — “the joiners form has no validation” survives a change of solution; “implement validation” dies with it.

The objection I get is that the organisation already runs several lists of actions — problem records, post-incident reviews, audit findings, risk treatment plans. It usually does. Corrective actions should live where they were born, with the register holding the pointer, the owner and the check date. Two lists, then, and the standard for moving between them should be deliberately unwelcoming.

The Intake Is Built, the Engine Is Not

Six moving parts, installed in the reverse of the obvious order

A working improvement capability has six parts: intake, which captures candidates; evidence, which sizes them; decision, which picks the few worth doing and refuses the rest; action, designed and resourced; governance, which keeps accepted work moving; and verification, which proves the change did what it promised. Most organisations have built the first and none of the other five, so the register is a funnel with no engine under it, accumulating claims rather than knowledge.

The reflex when it stalls is to improve the one part you have, which makes the organisation worse. Feed a better intake into a missing engine and all you raise is the volume of visible unmet commitment. The register stops being an untidy list and becomes an itemised account of what the organisation said it would do and did not. Each quarter it is shown, it argues more persuasively that improvement work never lands — a fair reading of the evidence, and a belief that outlives the register. Build from the back instead.

• Capacity at the front has nowhere to go — a better intake feeds a disposal step that does not exist, so the queue lengthens and its arrival rate becomes the complaint.
• A fuller register reads as an indictment — precision makes the gap between intent and delivery legible, and the people whose capacity you need are the ones reading it.
• The far end is the cheap end — somewhere for entries to be settled costs an hour a month of other people’s diaries; relaunching the register costs whatever credibility remains.

“We are not committed enough” has no next step; “we built the intake and nothing behind it” names five things to construct. The awkward part is that the cheapest of them does not involve improving anything. It involves asking other people to decide.

Where I Would Start

No budget needed — only the nerve to publish the numbers and reserve the hours

Resist the urge to relaunch the register with a new template and a fresh communication. That is the standard wrong answer, the only remedy its owner can deliver alone. Diagnose it in public instead, before the people whose capacity you need.

• Audit it before defending it — count the open entries, those with no named individual and those untouched for ninety days, and have its owner table the numbers.
• Split the list in two — ideas awaiting evidence in one place, accepted actions with owners and dates in another, collapsing duplicates as you go.
• Circulate a closure list once — a one-off clean-out, not a standing habit: a fortnight to object and fund, then close the rest with a stated reason, excepting audit findings and regulatory commitments.
• Book the hours with whoever owns the rota — five live actions, each with a named person and a weekly slot agreed with the manager who owns their other queue; a major incident reschedules it, never cancels it.
• Change the form last, and by one field — “what would tell us this is real, and how big is it?”, added once something exists to receive the answer.

The uncomfortable part of a cold register is that almost nothing in it is wrong. The entries are accurate, some quietly prescient about failures that later happened as described. The organisation saw its weaknesses clearly and had no mechanism able to act, which is more damning than never having noticed.

The parts downstream are next in this series, beginning with the measurement that tells you whether a problem is real. Until they exist, the register is not a plan. It is the organisation’s written record of what it already knew and declined to fund.

Hopefully this has been useful to you and I wish you well on your ITSM journey…