Cause of Error

A method for root-cause analysis

7. Next Actions

Every CoE has Next Actions.

Every Next Action must have a single person responsible, even if others are performing the action.

An action changes a system, a process or a document. It does not change how careful somebody intends to be.

Remind the team to test configuration changes is not an action. Nothing is different the following week, and when it happens again the next CoE will have to record that we reminded them. Make the pipeline refuse a configuration change that has not been applied in staging first is an action, because once it is done the failure cannot recur in the same way whoever happens to be on shift.

At least one action must address the class of failure rather than this instance of it. Rolling back the change was recovery, and belongs in the Timeline. Fixing the particular rule that was wrong is worth doing and prevents one thing. Making it impossible to ship that kind of rule without answering the question nobody asked is the action the Five Whys was for. A CoE whose actions all describe the specific failure has usually stopped asking Why too early.

Every CoE should also produce at least one action that shortens the time it takes us to find out. If nothing in this section changes detection, we have accepted that we will learn about the next one exactly the way we learned about this one — and in a good number of CoEs, that means from a customer.

Every Next Action must have a due date and a single person responsible for it.

Next actions — the shape, not the content

IDActionOwnerDueStatus
NA-1Restore the missing filter on pump 4 and inspect the other threeA named person2026-03-06Done
NA-2Specification review asks what the machine's surroundings will beA named person2026-04-17In progress
NA-3Alert on pump pressure, so the next one is found before it stopsA named person2026-04-24In progress
NA-4Retrofit filters across the older lineA named personAccepted, not doing

NA-4 is the one worth noticing. It is a decision, recorded, with somebody's name against it. Without that line it would be indistinguishable from an action nobody got round to.

A single person is responsible because teams do not have calendars and cannot be asked how it is going. This is not accountability in the punitive sense — the person named is usually not the person involved in the failure, and often had nothing to do with it. They are the person who will notice if it does not happen.

A due date is a date. Q3, next quarter and when the migration is done are not dates, and an action carrying one of them will never be chased, because there is no day on which it becomes late. Where the work genuinely does depend on something else finishing first, the action is to reach the next checkpoint, and that gets a date.

There is a tension about where these actions live and it is worth naming rather than pretending it is solved. Actions tracked only inside the CoE do not compete for anybody's time and do not get done. Actions handed straight to the general backlog lose the thing that made them urgent — within a fortnight they are indistinguishable from every other ticket, and they are reprioritised by people who have never read the document. Both of these happen constantly. The way through is that they go wherever the team's real work is tracked, and they carry the CoE reference with them, so that the reissue can find them and say plainly which are still open.

Some actions will not be done, and that is allowed, as long as it is decided rather than forgotten. An action we choose not to take is a risk we have chosen to accept, and it should be recorded here as accepted, with the name of whoever accepted it and the reason. Without that, the difference between a decision and neglect is invisible six months later, and the CoE quietly rots into a list of things nobody did.

Be wary of the long list. Twenty actions is usually a sign that the Five Whys stopped at symptoms, because every symptom acquired an action of its own. Four actions that change the class of failure are worth more than twenty that describe it, and they have the further advantage of being finishable.

It is normal that the first issued draft of a CoE document, contains actions that have not yet been completed. There are many ways to use this process, but we recommend the first draft of a CoE is issued as near as possible to the original failure event, ideally within 48 hours; but the document is re-issued and published when further analysis comes to light, and again when all Next Actions have been completed.

The reissue is what gives the due dates their force. A list nobody ever returns to is a wish list, and the commitment to publish the document again — with the same identifiers, and with whatever is still open still showing as open — is the only thing that makes the dates mean anything.

ver 0.2 rev 2026-08-02 status live