Countermeasure log

A log of what is being done about the causes behind the problems a team keeps hitting, and whether it worked. Every entry names the cause, says whether it is containment or a permanent fix, carries a named person and the outcome it is supposed to produce, and closes only with evidence that something moved and held. Two things make it different from an ordinary action list, and both come from the same uncomfortable finding: in the closest observational study of how people actually handle problems at work, nurses worked around roughly nine in ten of the failures they hit and removed the cause in about one. Everyone was busy, everything got resolved, nothing improved. First, this log therefore separates containment from permanent everywhere and reports what share of closures actually removed a cause. Containment is not failure — it is usually the right first move, and it protects people while the cause is still being understood. It becomes failure only when it is where the work stops. Second, the log records when a cause is seen again after its countermeasure was closed, which means the closure was never real. A team can close forty items a quarter and face the same eight causes all year, and without that check the log reads as a record of relentless progress. Add the date at the huddle the moment a cause reappears; it takes ten seconds and it turns a list of activity into a record of what is actually true. There is also a cap on how many entries may be open at once, because work in progress divided by throughput is how long each item waits — a queue without a limit does not go faster, it stops finishing. Influences, paraphrased rather than reproduced: Tucker and Edmondson on first-order versus second-order problem solving; Spear and Bowen on an improvement being a hypothesis with a predicted outcome rather than a task; and Little's law on why the cap is the only real lever on time-to-close.

How many may be open at once

Set the number of entries that may be open at once before you add the first one, and set it low enough to be uncomfortable — around five for a single team is a well-worn figure. The cap is the only real lever on how long an item waits, because work in progress divided by throughput is the waiting time. When you are at the cap and something new arrives, contain it and leave it off the log until something closes. That will feel wrong. It is the point: a list that only grows teaches everyone that adding to it achieves nothing.

The cause, what is being done, and what it should do

The cause in the same words every time, so recurrence is visible at all — write it once and reuse it exactly. Then whether this is containment or a permanent fix; be honest, because the whole value of the log rests on that one word. A named person, never a department. And the outcome you expect, written before you try it: "same-day replies back above 95% within two weeks", not "improve responsiveness". An action with no predicted outcome can only ever be done or not done — it cannot fail informatively, and an action that cannot fail teaches nobody anything.

Did it hold? — the cause coming back after closure

Close an entry only with evidence: what was seen that shows the thing moved, and held. "Done" is not evidence; a date is not evidence. Then keep the entry alive in one respect — if the cause turns up again afterwards, add that date to the entry that claimed to have fixed it. That is the single most valuable habit in this kata, and the cheapest. It costs ten seconds at a huddle and it is the only way anyone finds out that a closure was a hope with a date on it.

Patch or fix, and what actually stuck (computed)

Computed for you. The number that matters most is the share of closures that removed a cause rather than patching it — read it alongside the count of closures the cause outlived, because a high permanent share means nothing if those closures were not real. Also computed: how many are open against your cap, the age of the oldest open entry, how many closed with nothing written in evidence, the median time to close, and the causes that keep coming back. Nothing to enter here.

What the log says

Drafted from the log actually kept, and grounded only in what it computes.

The example below is the inside sales team from the performance grid, a quarter further on, working the two causes that grid's Pareto surfaced. Nine entries, seven closed, median eight days — from a distance, a team getting things done. Look at what closed. Only two of the seven were permanent fixes, and one of those was closed on a verbal agreement before anything had actually changed, after which the cause turned up twice more. So of seven closures, exactly one removed a cause and kept it dead: a published cover rota with four weeks of figures behind it that survived two absences. Meanwhile the one item that would genuinely stop deals slipping has been open sixty-five days, because it needs someone to change the qualification standard work. That is the ordinary shape of a real log — the easy contained things close in days, and the one that would change the system sits past its date.

• Counting a workaround as a fix

  It is the main way improvement systems decay while reporting progress. Patching keeps the day moving and leaves the cause exactly where it was. If most of what you close is containment, you are absorbing problems rather than removing them, and the log should say so out loud.

• Closing on the decision rather than on the change

  A sign-off, a verbal agreement or a ticket being marked done are not the thing working. Close when you have seen the number move and stay moved. Everything else is a hope with a date on it, and it shows up later as the same cause reappearing.

• Never recording that a cause came back

  Without it the log cannot tell the difference between a team that fixed eight things and a team that fixed the same thing eight times. The recurrence date is the cheapest entry on the sheet and the one that makes every other number honest.

• No cap on open entries

  A queue without a limit does not go faster, it stops finishing. Items age, people stop trusting the list, and raising anything starts to feel pointless — which is how the board that feeds this log goes quiet.

• Writing the cause differently each time

  One cause split across three wordings is three small bars instead of one obvious one, and the thing actually hurting you stays invisible. Agree the wording once and reuse it exactly.

• An action with no predicted outcome

  Then the only question anyone can ask later is whether it was done. A predicted outcome lets it fail usefully, which is the difference between a task list and a set of experiments.

• Letting it become a list of everything

  This log is for causes worth removing. Fold in every agreed task and the handful of entries that would change the system get lost among the ones that just needed doing.