In this post a few ideas for Other Steps you can take to improve what you learn from incidents are discussed.

In brief:

  • How to scope up a project to confirm that you are getting value from your incident reporting;
  • Aspects of what would be involved in implementing a mentoring program – that can address some of the common errors related to reporting and analyzing incidents, and;
  • Reviewing what a third party could do for your understanding of incidents – there is some real merit in a critical review by someone who is much less likely to get deflected by current imperatives (crises?) in the business and so will remain focussed on the important task of analysis.

Scoping up and Executing a Project

To paraphrase Steven Covey – a good basis to think about putting a project together is to – “Begin with the end in mind”.

The best way to do this is to think about the question you want to answer.  Asking the right questions is 10 times better than jumping on some quick answers.

Some suggestions on what these questions will look like are:

  • Is there a common control failure occurring in our business?
  • Are the Incidents that we are recording consistent with the broader industry data?
  • Are there any time or activity based trends in our incident data?

The kind of decision making improvements that can flow from asking these questions are:

  • Identifying that the Training system is not providing enough understanding to let people understand why they need to do their tasks in a certain way (or other general control failure that is broadly relied upon);
  • Site incidents don’t reflect the distributions of serious / fatal accidents.  This will highlight problems with characterization OR lack of reporting of a class of incidents, and;
  • There is a time of day that is prone to greater potential for human error OR major maintenance activities are generating a disproportionate share of losses on site.

Project Management in a nutshell

Once you’ve determined a small number of questions to answer – you then need to make sure there is a team in place to conduct an analysis.  The reason for employing a team – rather than relying on a single analyst (normally someone from the SHEC/Q team) is that you will get a better result.  Use a third party facilitator (internal or external) and follow a process which is rigorous enough to gather some learning from.  A typical task list for the project will be:

  1. Confirm project scope and goals with the key stake holder (this is a person in a decision making role – who will be the ultimate “owner” of any findings / recommendations from the project);
  2. Factual study – one or two individuals tasked with gathering facts from the Incident data base or other documented source OR by conducting some physical review of conditions (e.g. measuring some aspect of the plant or work environment in place) (Note – this may be an end point if the question to be asked was purely about the data in the incident database);
  3. Team session – confirmation of Scope and Mandate;
  4. Team session – generation of logical framework of elements that will respond to the question – such as:
    • Time line of events leading to a loss;
    • Key factors in a work area, or;
    • Input / Process / Output model for a business activity;
  5. Team session – identification of extra data needed to be able to complete the “picture” and achieve a good level of understanding (this could be questions that are suggested based on the facts gathered – that should be asked of identified roles in the business OR additional physical observations to be made OR further monitoring of a work place);
  6. Team session – organization of data into a framework that “completes” the picture / business models and identifies findings;
  7. Team session – prioritization of findings, and;
  8. Team session – generation of recommendations.

This is a suggested sequence – based on experience – but many other project plans would also apply.  Please get in touch if you’d like information on other project plans / task sequences that have been successfully applied to other analyses.

 

Implementing a Mentoring Program

Many incident data sets reviewed show many signs of that ubiquitous – Garbage In = Garbage Out problem that leads to organizations declaring a “too hard” status for managing their generation of information from the data.  I’ve explored some of the problems in earlier posts (see the Insidious Problem series) but a solution that will overcome many of the identified problems is:

  1. Simplify front line reporting requirements.  You want people to report more rather than less – so remove the friction of having to complete complex paper or on-line forms.  We have the technology to move immediate reporting using tools / techniques such as:
    • Photographs of an incident or hazard;
    • Video footage of the incident or hazard, or;
    • A combination of photographs and recorded voice / interview on the incident or hazard.
  2. Post process front line reports – using on or off site resources to generate consistent categorization of incident type, control failure and risk pathway implicated;
  3. Decide on next steps based on the real level of risk (i.e. data based – not opinion based) to either:
    • Aggregate the report as incident data;
    • Independently investigate the report using a single resource (on or off site investigator), or;
    • Unpack the report with a full team review.

Why is this equivalent to Mentoring?

The reason is that it meets the criteria of supporting positive moves (reporting more) encourages good questions (categorization of incidents) and allows for a feedback / improvement process to be structured and consistent.  This gets away from clunky systems with feedback processes that normally involve a decision maker having to weigh in with instructions on what to investigate based on “gut feelings” rather than evidence backed data.

 

Merits of Third Party Support

Apart from writing this as an exercise in shameless self promotion – there are real merits in using third parties to provide a consistent, “long view” of your incident data.

Third parties are also “blessed” with being able to specialize in a consistent mode of thinking.  The ORM team, for example, only focus on risk management activities:

  • Analysing losses;
  • Facilitating team sessions;
  • Developing risk controls, and;
  • Challenging assumptions and techniques of risk management systems (using tools such as auditing, near miss investigation and gap analyses to best practice).

So – as a potential value add that will:

  • Achieve consistency of analysis;
  • Reflect on issues outside a single business unit, and;
  • Have a contractual level of rigour – so that internal business pressures will not deflect analysts from the important (but rarely urgent) task of analysing incidents to best guide decision makers of emerging trends and current performance.

Feel free to contact Peter via phone or email to discuss requirements and further expand on this concept.  The ORM team have achieved some good results for clients in the past and would be happy to scope up a solution for your operation, division or company!

If you would like to “loop back” and read this series from the start – please click here.


Leave a Reply

Your email address will not be published.