Latest / Safe As Podcast / E61: Another deep dive on human performance in barrier systems

Transcript

E61: Another deep dive on human performance in barrier systems · Safe As Podcast

• 0:07
  Barriers, safeguards, controls, critical controls, bow ties,
• 0:12
  human factors in safety, critical domains.
• 0:15
  If you're involved with any of these, then this episode is for
• 0:18
  you. Good day everyone.
• 0:20
  I'm Ben Hutchinson and this is Safe as a podcast dedicated to
• 0:24
  the thrifty analysis of safety, risk and performance research.
• 0:29
  Visit safetyinsights.org for more research.
• 0:32
  Today's discussion draws on 4 separate reports, all focused on
• 0:36
  human performance in barrier or control thinking.
• 0:39
  Consider it an extension from episode 12.
• 0:43
  We're covering a lot of ground today saying strap in.
• 0:46
  We're starting with Manton ET al 2017 titled Standardisation of
• 0:52
  Bow Tie Methodology and Terminology via CCPs slash EI
• 0:57
  book. It's from the Ikemi Hazard 27
• 1:00
  Symposium. What they state is, is that for
• 1:03
  barriers to be considered as barriers, they must be
• 1:06
  effective, independent and auditable, and they must have
• 1:10
  the capacity to completely stop the threat from leading to the
• 1:13
  top event and must be independent of the threat and
• 1:16
  other barriers linked to the particular threat.
• 1:19
  In other words, barriers that don't meet the above criteria
• 1:23
  can be considered as safeguards. Moreover, they also add that
• 1:27
  safeguards also protect against the degradation of barriers.
• 1:31
  They argue that a common problem of bow ties is the generic
• 1:33
  hazardous situations and threats.
• 1:35
  For instance, LPG instead of 50 tonnes of LPG in a bullet.
• 1:41
  Often the threats and the top events aren't specific enough.
• 1:45
  Going back to the bow tie, prevention barriers on the left
• 1:48
  of the bow tie and then mitigation barriers are on the
• 1:50
  right. But to be considered a barrier
• 1:52
  they have to meet those other criteria.
• 1:55
  They have to be effective, independent and audible.
• 1:58
  In contrast to a full barrier. Safeguards prevent the
• 2:01
  degradation of barriers or support the execution of
• 2:04
  barriers. These include a host of
• 2:06
  organisational and management system barriers or approaches
• 2:10
  and and even cause some quite sort of strong controls still
• 2:14
  don't meet the definition of a full barrier.
• 2:17
  They argue to remove the simple human factors descriptors like
• 2:20
  procedures and training and competency as barriers in the
• 2:23
  threat lines. These don't meet the definition
• 2:25
  of a barrier and with more specificity they can be
• 2:29
  safeguards acting as degradation controls.
• 2:31
  They can help enable the effectiveness of the barriers
• 2:35
  and importantly, human error shouldn't be treated as a
• 2:38
  threat. Now, if you're familiar with the
• 2:40
  Icmm's critical control framework, this might sound
• 2:43
  relatively similar to you. A critical control can probably
• 2:46
  be considered pretty synonymously with a full
• 2:48
  barrier. This next section comes from 2
• 2:51
  core sources, Human Factors in Barrier Management from the
• 2:54
  Chartered Institute of Ergonomics and Human Factors.
• 2:57
  I highly recommend reading this report and also Mcleod's 2017
• 3:02
  paper, Human Factors in Barrier Management.
• 3:04
  Hard truths and challenges from process safety and Environmental
• 3:08
  Protection per SE provides some concerns about human and
• 3:12
  organisational factors in bow ties.
• 3:14
  For instance, it's misplaced to add human error itself as a
• 3:17
  threat. Despite being common, A focus on
• 3:20
  error places focus on its elimination rather than on
• 3:24
  establishing robust barriers and ensuring that they perform when
• 3:28
  and where needed. Hence, human performance and
• 3:31
  variability are among many other factors that degrade or enhance
• 3:35
  barrier performance. And while there is frequently
• 3:38
  performance specifications and expectations designed for
• 3:42
  equipment, rarely are these specifications articulated for
• 3:46
  human performance. Yet in my view, we don't set up
• 3:50
  the expectations for human performance, but then we're
• 3:52
  frequently surprised after the fact when people didn't operate
• 3:56
  like a computer. They also argue that in both
• 3:59
  eyes, top events are frequently too far to the right, leaving
• 4:02
  less time for mitigating sequences.
• 4:04
  For instance, problem solving, brickellage and expertise, areas
• 4:08
  where people excel allow a lot of safety capacities, and I
• 4:13
  think most people relate to this.
• 4:14
  But just too many barriers are identified, creating out what's
• 4:17
  important. Again, in the ICM Ms critical
• 4:20
  control framework, barriers are pretty similar to critical
• 4:23
  controls. So too many critical controls
• 4:26
  are identified, and if everything's critical, then
• 4:29
  nothing's critical. Next they cover some unrealistic
• 4:32
  expectations in human performance.
• 4:35
  They draw on the CS BS investigation of the Deepwater
• 4:38
  Horizon disaster. Unrealistic expectations about
• 4:41
  operating performance existed in the event that a well kick
• 4:44
  occurred and a well kicked by the way and often me a warning
• 4:48
  sign for a blowout. So some of the expectations held
• 4:52
  about the crew performance were that they would detect gas
• 4:55
  influx soon after it occurred, if it did occur, that they would
• 4:59
  quickly realise that the gas was over sufficient and concerning
• 5:02
  volume needing to be diverted and that they would quickly
• 5:06
  complete the correct sequence of actions to divert the gas.
• 5:09
  So given the task complexity, in fact cognitive complexity, a
• 5:15
  severe lack of time and financial incentives made it
• 5:18
  unrealistic that any crew would have had a realistic chance of
• 5:22
  taking these expected actions in time.
• 5:25
  So the company didn't hold realistic assumptions and
• 5:28
  expectations about the human performance to begin with for
• 5:31
  such a relatively cognitively complex task operating under
• 5:35
  various situational constraints like time and resourcing
• 5:39
  pressures. Finally, Mcleod's 2017 paper
• 5:43
  highlights that seeing people as a threat paints a negative view
• 5:46
  of people. In fact, people usually play a
• 5:49
  huge part in creating safe conditions.
• 5:52
  So some of these negative perceptions of human performance
• 5:55
  is focusing efforts on minimising human variability
• 5:59
  instead of improving barrier functionality or inherent
• 6:01
  safety, or eliminating or reducing the hazard exposures.
• 6:05
  We don't focus enough on removing the potential for error
• 6:08
  out of a situation. We'd better design what
• 6:11
  contusive human centred practises instead.
• 6:15
  Quoting the article. People are nearly always a
• 6:17
  positive element in complex systems and we should be
• 6:21
  striving to create human centred work designs, reliable
• 6:24
  environments and setting people up to succeed.
• 6:27
  Hence we need to be specific on what performance we expect from
• 6:30
  people under what circumstances. Now these reports provide a lot
• 6:34
  of suggestions, so here's just a few.
• 6:37
  How will the barrier performance directly affect the threat?
• 6:41
  Who delivers the required performance, including who
• 6:43
  detects the barrier functions? Who decides what action to take
• 6:47
  and when? What judgments and decisions are
• 6:49
  needed, and will they be able to make those decisions under the
• 6:53
  expected conditions? Do any human factors standards
• 6:56
  exist? Have we considered the situation
• 6:59
  that the operators operate in time for decisions?
• 7:01
  What information they will need and what information will they
• 7:04
  actually have? What happens if they miss some
• 7:07
  of this information or some of these critical cues?
• 7:10
  And a bunch more? Next, a further set of barrier
• 7:13
  and human performance limitations are covered.
• 7:16
  Barrier models rarely take a system's view of human and
• 7:19
  organisational factors. How will organisational factors
• 7:23
  like production pressures, trade offs, resources affect barrier
• 7:27
  functionality? We rarely consider task
• 7:29
  complexity and hence organisations often hold
• 7:33
  unrealistic expectations of people.
• 7:35
  But we're not machines. Barrier models are often
• 7:39
  designed or implemented and communicated in ways not
• 7:42
  conducive to work as really effectively understanding nor
• 7:46
  being supported in the barrier systems.
• 7:49
  For instance, it said, workers are frequently unaware of what
• 7:52
  the barrier is capable of, or the significance of a task, or
• 7:56
  even their assigned role in the whole barrier performance
• 7:59
  system. In other words, barrier models
• 8:02
  were often developed as paperweights, constructed
• 8:04
  separately to the people expected to use them.
• 8:08
  Most importantly, I think there's often a lack of
• 8:11
  awareness on the differences between workers imagined first
• 8:14
  work is done, a barrier models are built upon, many workers
• 8:18
  imagine and workers prescribed assumptions rarely validated in
• 8:22
  the field and rarely capturing the compromises and adaptations
• 8:25
  made when carrying out tasks under real well, constraints and
• 8:29
  pressures. So when all the authors suggest
• 8:32
  that too much focus goes into trying to micromanage
• 8:34
  performance, sending negative message of the role of human
• 8:39
  performance in creating safe work most of the time.
• 8:43
  Moreover, there's a risk that we focus so much on optimising
• 8:46
  technology, relieve people reluctantly with whatever is
• 8:49
  leftover. Such an attitude conflicts with
• 8:52
  the user centred view of socio technical systems.
• 8:56
  And most importantly, this approach misses the opportunity
• 8:59
  to build flexibility and adaptability into systems
• 9:02
  through a deeper understanding of the ways people contribute to
• 9:05
  resilience and avoid undesirable consequences.
• 9:10
  Finally, specific questions and prompts provide around what
• 9:13
  makes for an effective human burialment, like clear and
• 9:16
  specific tasks and goals. Again, way too much to cover, so
• 9:20
  I highly recommend checking out the sources.
• 9:22
  But some of the realistic performance expectations that
• 9:25
  need to be said include things like identifying the situation
• 9:28
  clearly, knowing or being able to work out what needs to be
• 9:32
  done, being able to do it in the time available with the
• 9:35
  available resources under the likely conditions or maybe even
• 9:40
  under unexpected conditions for adverse operating conditions,
• 9:44
  having means of knowing that the action had the intended effect.
• 9:46
  Some sort of feedback. People need feedback.
• 9:50
  An example for specifying human performance is provided for
• 9:53
  lifting operations and they talk about highlighting different
• 9:56
  detect, decide, act sequences. I won't go into that here, but
• 9:59
  it's really about elucidating what information and key
• 10:02
  decisions need to be made, what sort of feedbacks available for
• 10:06
  people, and any critical expectations on human
• 10:09
  performance that's needed for the barrier to be effective.
• 10:12
  Now, the final source I'm talking about are almost at the
• 10:14
  end. I'm drawing on another source,
• 10:17
  this time from the WA Department of Energy Mines, Industry
• 10:21
  Regulation Safety. There's an information sheet on
• 10:24
  human factors that integrate human factors into bow tie
• 10:27
  analysis that provides some useful checklist prompts around
• 10:31
  the specification of people in a barrier system.
• 10:34
  Again, there's too much to cover, but some of these prompts
• 10:37
  are things like have we actually properly modelled human factors
• 10:41
  and failures in the bow tie, and have we modelled these human
• 10:45
  factors and failures as a threat or a top event?
• 10:47
  If we have, we shouldn't have done that, ensuring that human
• 10:50
  factors is considered as a degradation factor for a
• 10:53
  barrier. That is, again, factors that
• 10:56
  enable or degrade the barrier effectiveness, usually enabling
• 11:00
  but not always. Have we identified relevant
• 11:03
  competencies that are required for that barrier to be
• 11:06
  effective? Have we considered the processes
• 11:09
  for the functionality and any safety critical evaluation for
• 11:12
  the task? Have we considered supervision
• 11:15
  that's needed? What info or data is needed and
• 11:18
  when, and who needs it? And what if that info isn't
• 11:22
  available? What's the worst thing that can
• 11:24
  happen or the most credible scenario that can result if that
• 11:26
  information isn't available? Have we considered human machine
• 11:29
  interactions in design, implementation and maintenance
• 11:32
  phases? And a bunch more.
• 11:34
  That's it on Safe As I'm Ben Hutchinson.
• 11:37
  Please help share, rate and review, and check out Safety
• 11:41
  insights.org for more research. Finally, feel free to support
• 11:45
  Safe As by shouting a coffee link in the show notes.