This is tryptic thoughts based on the question of whether near miss reporting is Reactive or Proactive. Of course it’s a little bit of a trick question, which is why it leads into several lines of discussion.
- It depends on the exact definition of a near miss.
Strictly speaking if we mean something that happened that could have resulted in injury then we’re already talking about a past event so it’s reactive. However, if we’re talking about an injury it didn’t happen but might in the future so it’s Proactive. Hmm… or is it?
Simply reporting the event does precious little to prevent future harm. It needs to go into a functioning action tracking system and someone needs to accept responsibility for doing something that reduces the risk of harm. That’s a whole new can of worms. One of the key indicators of how proactive the whole system really is comes from understanding the requirements of the ISO management system standards. They all call for corrective and preventative actions to be taken. Most organisations have a reasonable handle on corrective actions: – Investigate the incident and put counter measures in place to reduce the risk of a recurrence.
Once again though, that’s reactive thinking. To be truly Proactive you need to look not only at a particular incident but also consider both whether it’s part of a trend and also whether this particular incident highlights a larger underlying problem than the immediate causes of the recorded incident. If that’s the case there’s the potential to prevent many future incidents before they are even reported as a near miss.
- Is near miss the right name anyway?
Our work on Safety Culture in the area of using language as a source of cultural clues has thrown up several interesting alternatives to ‘Near Miss’. Perhaps the most obvious is a technical change to ‘Near Hit’, based on the claim it’s more accurate. Other terms include, ‘Learning Opportunity’ (A euphemism perhaps?); ‘Close call’; ‘Good catch’; and ‘Safety concern’. Each has a different slant and can give a clue about the wider context as rule of thumb we’d encourage you to consider those at the end of the list first. We’d be interested to hear of others any learn a little about the background of how they came into use. Click here to let us know.
The most common issue we encounter when discussing the near miss reporting is a lack of clarity about what constitutes a near miss. For example is an unsafe condition a near miss? Is getting a knock on the funny bone an accident, incident or near miss? Often the safety management system will have more than one system with potentially overlapping and even conflicting uses.
At the extreme there may be an accident reporting system (plus an environmental incident system plus a quality defect reporting system); a near miss reporting system; a hazard reporting system; an accident investigation system; an audit non-compliance system (or three!), a behavioural observations system, an employee suggestion scheme (or three!), a Management safety tour system, oh, and a customer complaints system.
My previous work on Management system software led me to the conclusion that in most customers there was massive duplication both in systems and data recording. All the above systems share twin common goals – Assurance that processes are under control and identification of opportunities for improvement and a common generic process and data set. Also, whatever the source of the opportunity it needs to go into the system, generate one or more SMART actions to effect the improvement and ultimately generate the gain.
Which is why our term that addresses all of the above is an ‘OOPS’ that is something that’s gone ‘Out Of Process Somehow’. What an opportunity to simplify, clarify, streamline multiple potentially confusing systems and get a huge thank-you from everyone involved.
- Why bother reporting an OOPS anyway?
Now we’ve established that there’s a generic term for all risks to the integrity of the management system and we could have a single system to capture them it still leaves the ‘So What’ test.
The answer to that is in two, interrelated, parts. Firstly from the organisation’s perspective there’s the opportunity by collecting data, analysing it, acting the analysis and checking the change had the desired outcome both to reap the safety (and often efficiency) gains and to set up the opportunity to motivate the workforce. That’s where the second part comes in.
We’re often asked how we can improve participation in reporting and we advocate a two step approach. The system has to be simple to use and having used it there needs to be a benefit to the reporter.
Dealing with the second one first there are at least two ways a reporter can get a positive outcome from reporting. Make sure that for each report there is direct feedback to the person making the report. Ideally this should cover
- A basic thank-you for taking the time and making the effort in the first place.
- If there’s going to be any time lag between reporting and implementing a change that a reasonable expectation is set and met. (even if meeting the initial estimate is an explanation of any delay).
- An idea of who is going to consider the suggestion.
- How they can get involved in designing potential solutions.
- The final outcome.
- Any reasons why an idea or suggestion is considered impractical.
In practice of course that’s several different opportunities to engage at different times and the more that can be a dialogue and in person rather than an email or bulletin the better.
Turning to making it easy to report and addressing the original question of reactive or proactive there’s an anecdote I’d like to tell. Many years ago when I was first responsible for implementing an ISO management system I wrote what I thought until recently was just about the simplest and easiest Incident reporting system possible. It consisted of just two words: “Tell Paul”. That with the feedback process above served me well over many years and was a source of some pride. Then recently I was reflecting about a creating a proactive culture and I realised there was a potential improvement.
The potential barrier was that “Tell Paul” actually relies on individual employees being proactive whist from an organisational perspective the procedure itself was culturally reactive. As the representative of the organisation I was waiting to be told. In order for the system to be effective it requires individuals to be MORE proactive than the prevailing culture.
After the initial shock I thought about how to remove the long-time latent OOPS. So here’s the corrective action – the procedure now reads ‘Paul, ask’. So now we have a culturally proactive procedure in the system and since I’m part of the management the responsibility now sits in the right place. If more data is required all that’s needed to generate it is action on my part, with all the associated upside of getting a chance talk to people about a subject that they regard as important.
“And the preventative action?” I hear you ask – well my fondest hope is that this article covers that requirement.
By Paul Bizzell