Classifying behaviour to prevent accidents

When we look into accidents, we must look to their antecedents, or causes  We look at what occurred just prior to the accident, or to a series of events which occurred before the accident. Was what happened this time different in some respect to what always happens?  If so, why the difference this time?  If not, are there often possible accidents and near misses happening as a result of an ineffective ‘system’?

We are, in essence, trying to classify error.  We can do this by looking at:

• Omissions- failures to get to a required goal
• Commission- doing something wrong or doing something right, in the wrong context
• Extraneous activity - doing something extra within a task, which is harmful 

So, it's not all about disobeying the rules, nor is all about a freak piece of 'bad luck', nor indeed, a faulty piece of equipment, although all of these can and do occur and can explain some accidents.

However, in order to try to prevent more accidents, we must also try to look to things we do that we can ascertain are either wholly or partly the cause of error, and then change that pattern of behaviour and highlight and reinforce the change across our organisations.

Classification packages

There are a number of different classification packages, which have been developed in order to assist in this area of activity.  Briefly, they are:

• PHECA - Potential Human Error Cause Analysis and
• SHERPA - Systematic Human Error Reduction and Prediction Approach

Both have manual and computer versions.  For instance, PHECA uses a system of prompts for task type and human errors:

• Task - operation, maintenance, check, monitor, communication
• Errors - Not done, part of it done, less than it done, more than it done, other thing (similar) done, as well as, repeated, sooner than, later than, miss-ordered
• SHERPA links both task types and error types together to get a combined set of prompts but keeps error causes separately stored

It is important to distinguish between error types and underlying causes.  An 'error type' should be tied back to defined performance goals and thus a human task - i.e. blade only partly covered by guard.  Causes will be linked to the relevant underlying stage of the human action chain within a human information-processing model and classified into either a skill, a rule or a knowledge based error.

Examples of the causes of error are the following:

• A wrong mental model - a person pictures the way something is best done and does it that way as it appears immediately the 'right' way, although it is not. The cause of this can be lack of training, lack of re-enforcement of training, out of date procedures, bad modelling
• Risk tolerance - error occurring because a person believes that it's worth it to have a few errors  week as it is made up for by the quicker way of working.  This is allowed occur due to poor supervision locally, insufficient training on safety, insufficient reinforcement, both positive and negative and lack of monitoring
• Demand overload - error occurring because a person makes mistakes or slips - too many high capacity requests, plus operational tasks, and incidental queries over-riding the person's normally safety thinking which results in chaos and error/accident.  The cause is obvious - too many demands, not enough supports and can be referred to as stress-related error