Prevent recurrence through controlled change

Immediate causes and contributing conditions

The immediate failure mechanism is how the event actually happened. Contributing conditions explain why it was able to happen, or why it was not caught sooner. A useful investigation can look at equipment behavior, configuration, maintenance records and how the work process is designed.

Stopping at 'operator error' usually leaves important questions unanswered. The instructions may have been unclear. The equipment may have been hard to identify. The person may have had no feedback that something was wrong. Look at the whole system. Do not invent facts or assign blame from an incomplete record.

Prevention needs a measurable outcome

A preventive change should target a cause that the evidence supports. It also needs a clear way to judge whether it worked. Record the baseline, scope, owner, acceptance criteria and follow-up interval. Judge any improvement under comparable conditions, not from one good-looking snapshot.

A small pilot can reveal side effects before the change goes wider. If the original fault goes away but another problem gets worse, the change may need revision. If the observation period is too short to show the fault has stopped coming back, say so.

Restoration is only one outcome

An incident can have three separate outcomes. Containment limits the impact, for example by keeping the problem from spreading. Restoration gets service running again. Prevention aims to stop the problem from coming back. Replacing a damaged module may restore output without explaining why it failed. Record each outcome separately, and keep the evidence a vendor or specialist will need to investigate.

Make an improvement falsifiable

Falsifiable means a test could show the idea is wrong. An explanation becomes testable when it predicts a result that might not happen. Say a configuration fix is expected to reduce repeated disconnects. First define which disconnect events count, which units are included and what comparable observation period you will use. If disconnects keep happening under that plan, that weakens the case for the fix. A successful boot alone does not test it.

Count bad outcomes in the decision, not just good ones. Say the acceptance plan requires fewer alarms and no loss of accepted work. A pilot that cuts alarms but lowers accepted work has not passed. Record the bad result next to the good one. Then follow the approved stop, rollback or revision decision. Get operational and safety approvals before the pilot starts. Do not rewrite its success criteria after you see the results.

Worked example: the useful unsuccessful pilot

An approved pilot is meant to reduce repeated disconnects. It finishes its observation period with no improvement. The control group, similar units that were not changed, stays comparable the whole time.

The pilot still produced useful evidence: the change did not meet its goal under those conditions. Record the result, carry out the approved next decision and rethink the explanation. Do not quietly change the goal to ‘the equipment still boots’ just to justify a full rollout.