Choosing What to Improve
A register with ninety open entries and no ranking is functionally the same as no register at all. Choosing what to improve, and recording what you have declined and why, is the discipline that separates improvement work that compounds from improvement work that stalls.
Series: The Improvement Engine, Post #3
Choosing What to Improve
Nobody has ever argued with me about whether a register was complete. The arguments are always about the order — which is odd, because almost no register has one worth arguing over. Ninety-odd entries sit in the sequence they arrived in, and “by date raised, mostly” gets offered as though sequence were a filing convention rather than the thing deciding what an engineer picks up on Monday.
It is a suggestion box with a version number. An unranked register does not avoid prioritisation; it does it badly, invisibly, and unaccountably. Prioritising improvement is a capacity-budgeting problem dressed as a scoring one: entries cannot be ranked against each other, only against the operational work each would displace. An order set by a room that lacks that capacity is a preference, not a ranking — which is why registers sit in date order in organisations well able to sort spreadsheets.
Four Dimensions That Survive a Steering Group
Scoring that holds up when somebody senior disagrees with it
A ranking needs a decision rule; the frameworks give a shape for the work instead. The improvement register is a v3-era artefact carried into ITIL 4, and neither edition ever said which entry goes first — a silence read as permission not to decide.
ISO is more demanding and still stops short: clause 10.2 of ISO/IEC 20000-1:2018 requires improvement opportunities to be evaluated and prioritised, and the criteria for doing so to be determined and documented. It sets no bar for the criteria, which is how “date raised, then whoever asks twice” passes an audit.
- Value in the organisation’s own units — engineer hours returned, incidents of a named category avoided, an audit finding closed; “improved efficiency” is not one.
- Effort and risk are separate questions — effort is what the work costs, risk what it costs if it fails or is left alone.
- Confidence is what ITSM drops — a modest benefit you are sure of outranks a large one nobody has tested.
Every scoring model gets gamed — the numbers reverse-engineered to justify the answer somebody arrived with — and one nobody has gamed has not been used by anyone senior enough to matter. A score does not compute the order; its job is to force disagreement into a named dimension, so a rank is contested out loud on value, effort, risk or confidence rather than tone. I would resist a fifth: it gives that argument somewhere quieter to go.
What Quick Wins Quietly Cost
A culture of small victories starves the fixes that end whole classes of incident
Quick wins earn their reputation honestly: early on you need visible results, and cheap items deliver them. The trouble is when they become the only work that completes.
Meanwhile the structural fix sits at position forty: expensive, spanning two teams, capable of ending a whole class of incident, and on an effort-weighted ranking it never rises. The score is not wrong; effort is doing exactly what it was asked to.
- Quick wins optimise for the reporting cycle — anything that cannot show a result before the next steering meeting loses, whatever its merit.
- Cheap items crowd the calendar, not only the ranking — six two-week wins and one long fix compete for the same reviewer and change window.
- Structural work needs a reserved place in the order — ring-fence a third of the ranking for causal work, and the same share of what gets reported.
The idea that quick wins build an appetite for larger work has a ratchet against it. Delivered volume is the number a forum is judged on, so a quarter spent on one structural item reads as a bad quarter, and its sponsor pays a reporting cost the sponsor of six tidy-ups does not. Ring-fencing the order alone will not hold; cheap items are raided back through the status report.
The Portfolio and the Backlog
A handful of items you fund, and everything else you pull
Most organisations run one list for two incompatible jobs: the three-quarter platform remediation needing a sponsor and a budget line, and the twenty-minute knowledge article fix raised on Friday. Force both into one ranking and the cheaper sort wins. Split them: six sponsored items with funded capacity, and a backlog of the rest.
A third class belongs on neither list — a nonconformity raised at audit, a regulator’s finding, a contractual remediation commitment. These arrive with a date and are ranked against nothing: the rule’s first plain application, since they take capacity before the ranking begins. The honest consequence is a smaller portfolio. A forum that quietly ranks an audit finding into next year has not prioritised it; it has created a second nonconformity.
- The portfolio is chosen, the backlog is pulled — entry to one is a funding decision by named people, entry to the other cheap triage.
- Externally imposed dates are not candidates — take them off capacity first, then rank what remains.
- The entry test is who would be asked — if nobody would answer for an item still undone in a year, it is backlog, never portfolio.
Keep the portfolio small enough that a seventh item obviously means removing one; anything larger is a wish list with sponsors attached.
A Limit on What May Be In Flight
The half-finished improvement is the most expensive item in any register
Improvement is exposed at the finish line: it is almost never anybody’s day job. When a major incident lands, the half-finished item is set down — all cost incurred, no benefit realised.
A published ranking is only tested at the moment something starts. Every other mechanism here produces a document; the work-in-progress limit is the only one making the order binding rather than advisory, because it is where starting the wrong thing must be refused in front of somebody. Borrow it from Kanban, start at one per named owner, and apply it to the sponsored portfolio.
- Count what is in progress, not what is open — forty open with nineteen started is worse than eighty open with three started.
- A full board is a decision point, not a failure — nothing starts until something finishes, and the argument over what is displaced is the point.
- Record the state of anything you set down — parked with its progress written down, an item resumes; parked silently, it restarts from scratch.
The objection is never really throughput. A limit turns an invisible queue into a visible one, and whoever must then tell position forty it will not start this quarter is the chair — which is why organisations prefer queues they cannot see. The queue always existed; the limit settles who admits it.
Rejection Is a Service, Not a Rebuff
Saying no in writing is a kindness; silence is not
Nearly every register I open has three states: open, in progress, done. Almost none have a fourth that says declined, with a reason, a date and a name. Nobody wanted to write “no” next to a colleague’s idea.
So silence stands in — and silence is not an absence of decision but a decision to spend the raiser’s attention on your behalf, indefinitely. A decline is paid for once, by whoever takes it; no decline is paid for repeatedly, by somebody who keeps checking.
- Record the reason, not just the verdict — “not now; capacity is committed elsewhere until Q3” is useful; “closed” says only that they wasted their time.
- A decline is a judgement on current information — say so, and invite the entry back if the evidence or cost changes.
- Publish the decision always, the reason where you can — some reasons are unpublishable; those entries still get a date, a name and a private decision.
A considered no within a fortnight shows more respect than a polite maybe lasting two years, and an entry that could never be declined was never ranked, only stored. The decline is what makes an order real. Never publish a reason you know to be untrue — a log that lies teaches contributors faster than silence.
Somebody Has to Decide
A named forum beats a room full of agreeable people
Ask who decides the ranking and the answer is that it gets discussed at the service review. The list leaves that meeting longer than it arrived.
Consensus is a fine way to build support and a hopeless way to prioritise: its output is the longest list that offends nobody. What works is a named forum with a standing agenda item, a quorum, and a chair whose name sits against the ranking.
- Put the order with whoever pays for the failures — the service owner living with the incidents, not the ITSM manager, who ranks by tidiness.
- The forum must control the capacity it allocates — ranking work it cannot fund or staff produces recommendations, not decisions, and attendees notice.
- Publish the ranking, not the minutes — an order living only in a discussion has not been decided, and position forty cannot see where it stands.
In my opinion the test of a forum is not how well it ranks. It is whether it has ever moved somebody’s item down in front of them and said why — and whether anybody appealed. A ranking no raiser has contested in a year is ignored, not obeyed; a forum that never overruled anyone senior is untested.
Where I Would Start
Putting an order on a register that has outgrown its usefulness
A fortnight, one hard conversation about who owns the order, and a tolerance for saying no in public. That is the entire bill.
- Rank your top ten by hand and read the order aloud — to three people who will disagree, before you publish.
- Add a declined state; a spreadsheet column will do — use it on twenty entries, with a reason and a date, and tell each raiser.
- Separate what you fund from what you pull — six sponsored items at most, everything else on lighter triage; a second axis, not a repeat of the ideas-and-actions split.
- Set a work-in-progress limit and enforce it once — the first refusal to start because the limit is full is when it becomes real.
- Propose the accountable name and make somebody refuse it — take one name to the next service review and ask for confirmation.
The organisations whose improvement work compounds are not those with the most ideas. They ranked a short list, protected the capacity to finish it, and told people what became of the entries they turned down. None of that makes a good slide.
Choosing is where improvement stops being a sentiment and becomes a commitment of capacity, taken from somebody who wanted to spend it elsewhere: an order is worth what the room announcing it can fund. The next problem arrives at once — whether the item is written well enough that a competent person could pick it up and know what finished looks like.
Hopefully this has been useful to you and I wish you well on your ITSM journey…