Below is a small screencast of our Online bowtie practitioner course, in which we did a bowtie on employee kidnapping, and came across an interesting issue. We had barriers with multiple levels of detail. But ideally, the barriers in a bowtie are on the same level of detail.

It's not a hard requirement to have the same level of detail, but it makes the bowtie cleaner, easier to read and, if you choose the right level of detail, more specific. In this case, we fixed the bowtie by moving the more general barrier into an underlying activity. Watch the clip below to see what I'm talking about:

A study described in the book Controlling the Controllable (Groeneweg, 2002, p. 88-89, experiment 2) looked at the ability of incident analysts to distinguish relevant from irrelevant information. The results are intriguing and may put our own incident analyses into perspective.

The experiment

Participants were divided into two main groups: A ‘trained’ group that received instructions on incident analysis using fault trees (N=15) and a group which received no instructions (N=15). Each of the participants were given a set of 128 event descriptions related to a fictional incident concerning a ferry. 107 of these events were irrelevant to the causation of the incident and 21 events were relevant. The participants had to select the relevant events.

The original study also included a small group of experienced investigators. For these, no statistical differences were found. This may have been due to the small group size. For reasons of brevity, I have omitted that part of the study.

The results

In the untrained group, on average, 8.2 relevant events were correctly identified. This means that 60% of relevant information remained unidentified. In the same group, 12.5 events were selected as relevant, while they actually were not.

The trained group, on average, identified 12 relevant events correctly which means that still 48% of relevant information was not reported. Compared to the untrained group, this difference proved statistically significant. In the same group, 12.4 irrelevant events were reported as relevant.

What does that tell us?

First, it is comforting to see that the group that received some training identified more of the relevant information compared to the untrained group. This seems to suggest that training does indeed pay off.

But more interestingly, a relatively high percentage of relevant events remained unidentified. Even in the trained group, still 48% was missed. The pool of selected events was further diluted by a large number of erroneously selected irrelevant events. These results were obtained under laboratory conditions, with cleanly written event descriptions that were identical to all participants. In an actual analysis, the ambiguity of information is likely to be much higher and as a result the percentage of identified relevant data is probably even lower.

This raises the question: If we on average only find less than half of the relevant information, is all incident investigation futile? If our sole goal is to describe everything that happened on that location during the incident, then yes, perhaps we are doomed to be incomplete. But if our goal is to find ways to improve our organization, a lot can still be pieced together from that 50% through careful analysis.

Next time you’re looking at an incident report, keep in mind that you might only be looking at part of the story. But at the same time, if that analysis leads to demonstrable improvements, it may just have been worth it.

James Reason's classic book Managing the Risks of Organizational Accidents has a lot of great risk management insights. Here are three paragraphs on adding too many procedures over time (p. 49):

All organizations suffer a tension between the natural variability of human behaviour and the system's needs for a high degree of regularity in the activities of its members. The managers of hazardous systems must try to restrict human actions to pathways that are not only efficient and productive, but also safe. The most widely used means to achieve both goals are written procedures. But there are a number of important differences between the procedures for production and those for protection.

Although by no means immutable, the procedures designed to ensure efficient working tend to arise fairly naturally from the nature of the productive equipment and the task to which it is put. Safe operating procedures, on the other hand, are continually being amended to prohibit actions that have been implicated in some recent accident or incident. Over time, these additions to the 'rule book' become increasingly restrictive, often reducing the range of permitted actions to far less than those necessary to get the job done under anything but optimal conditions.

Figure 3.1 illustrates this shrinkage of allowable action as it occurs over the history of a given system. This could be a chemical process plant, a railway, an aircraft operating company - or any hazardous technology at risk to organizational accidents. The space between the shaded areas represents the scope of prescribed action. As time passes, the organization inevitably suffers accidents and incidents in which human actions are identified as contributing factors. After each event, the procedures are modified so as to proscribe these implicated actions. As a consequence, the scope of allowable actions gradually shrinks to a range that is less than that required to perform all the necessary tasks. The only way to do these jobs is to violate the procedures.

These are just three paragraphs of condensed juicy safety wisdom. I encourage you to pick up a copy and read the rest. It's just as good.

The best definition of a safety barrier can be found in an article by Sklet from 2006:

Safety barriers are physical and/or non-physical means planned to prevent, control, or mitigate undesired events or accidents.

This definition has an interesting word. Planned. It implies that besides stopping unwanted events, a barrier is also organised formally. But by only looking at formal barriers, two aspects of safety are left out.

First, because we're excluding informal barriers. Someone that happens to walk on the beach and saves a drowning child is not a barrier because it hasn't been formally organised, while a lifeguard that does the exact same thing is considered a barrier. It's the combination of formal and informal barriers that keeps an organisation safe. They complement each other. However, if we measure the safety in an organisation, the focus is often put on formal barriers because they're easier to measure. This creates a blind spot for the informal side of safety. To prevent this, concepts like HRO (High Reliability Organising) and resilience engineering aim to strengthen our ability to deal with scenarios even if we haven't planned for them.

Second, there are many formal systems whose goal isn't to improve safety, but do so as a byproduct. Things like simplifying a proces to save costs, or a teambuilding exercise. If we didn't plan these things to increase safety, they're not considered barriers and aren't treated as such, event though they might have a positive effect.

In the end, there are many factors, both formal and informal, that increase safety in an organisation. The question is why do we even want to consider some of them as barriers? The reason is that we have to focus our efforts. If we think everything is important, it's hard to know where to start improving. Barriers are one way to focus on those parts of the formal organisation that are important to reduce our risks.

But once you're confident that all those formal barriers are working, don't think you're done. It's time to widen your view and look at the rest of the formal and informal factors that keep your organisation safe.

* Sklet, S. (2006). Safety barriers: Definition, classification, and performance. Journal of Loss Prevention in the Process Industries, 19(5), 494–506.

Which risk barriers are the most important? This question can be answered by assessing barrier criticality^[1]. It allows organisations to prioritise their effort on barriers you really can't afford to fail. In this article, we'll discuss why & how to approach barrier criticality as well as some challenges.

Why use barrier criticality

So what problem does barrier criticality solve? First, all organisations have a limit on resources to invest in risk reduction. Those resources need to be distributed among all the possible measures to reduce risk. Barriers that are critical will get more resources. For example, critical barriers could be checked more often than others.

Another reason for criticality is focus. People can only deal with a limited amount of information, whereas risk analysis gives you a complete overview of all the relevant risks and barriers. Giving people a smaller set of critical barriers makes it more likely they will get managed. The counter argument is that it's extra easy to ignore everything that isn't critical. This is a good reason to make sure you think about how you will deal with all levels of criticality, including the lower ones (see the challenges below).

How to assess barrier criticality

Criticality is assessed using a combination of 3 components.

1. Scenario size
2. Barrier effectiveness
3. Barrier redundancy

Scenario size

Barriers are built to prevent one or more scenarios. These scenarios (also called threats or consequences) are not all the same. They have different frequencies and power to cause negative consequences. The more a scenario contributes to the overall risk, the more critical barriers against that scenario become.

Barrier effectiveness

Not all barriers are equally effective in stopping a scenario. Some are more effective than others. A barrier that is more effective is usually also more critical, because losing it would mean a greater reduction in protection against the scenario.

Barrier redundancy

If a scenario is protected by multiple independent barriers, losing one of them is less of a problem, which makes it less critical. Of course it's still important to maintain the group of barriers, but it's less critical than a single barrier that is responsible for controlling a scenario or barriers that share dependencies, making them less redundant.

Combining them

You combine these three components to select barriers that are highly critical. In the picture above, we can see a critical barrier in the first scenario that is there because it's a) on a high threat scenario and b) it's very effective (shown by the green colour). The other barrier on that line is a little less effective (orange), so we decide not to make that one critical because we already have such a good barrier on that line.

The second line also has a critical barrier, even though the threat scenario is medium and the effectiveness is poor. However, it's the only barrier on that scenario line, so we still regard it as critical.

This shows that these three criticality components can combine in different ways to mark a barrier as critical. But in all cases, they are either on a high risk scenario, have few back-up barriers or are highly effective. In an assessment, you can combine this with the expertise in the room, because there might be other exceptional circumstances which make a barrier critical or not.

Challenges

Let's also look at two challenges when using criticality.

Too many critical barriers

The core use of criticality is to take a longer list of barriers, and make a short list to focus on. But what do you do if you still end up with a long list of barriers? The simplest solution is to increase the threshold of when you find something critical. For instance, you could decide to never regard a barrier critical on a medium sized threat, or to have at most 1 critical barrier per line. If you describe this in a method policy, it can make discussions with barrier owners easier, as they sometimes assess their own barriers as the most critical.

Only looking at critical barriers

One of the big problems with criticality, are barriers that aren't highly critical. It can be easy to forget about them. Make sure that your method policy considers how to treat each level of barrier criticality. Low criticality barriers should still be managed after all. An example could be to report on the performance of critical barriers monthly, whereas the full set is reported on quarterly or yearly.

Conclusion

Criticality can be a powerful tool to create a short list of important barriers to devote more resources and attention to. It is a combination of scenario size, effectiveness, redundancy and expert judgement. Make sure to have as few critical barriers as practicable, while at the same time having a plan to not forget about the barriers that have a lower criticality.

[1] Just to be sure, when we talk about criticality here, we mean it in a positive way (as in, this is critically important). We don't mean the criticality of a negative event (as in, this is critically bad) like in FMECA.

It can be a challenge to know what to use bowties for. In this webinar we show different practical applications of bowties. From risk communication to barrier monitoring and decision support.

I hope you'll forgive me, but I don't really like 5-why. It's a decent methodology (especially if you don't do incident analysis often), but in my opinion there are better options. Instead, we can use barrier-based incident analysis methods like Tripod Beta, Barrier Failure Analysis or BSCAT. I'll use Barrier Failure Analysis (BFA) to explain. If you don't know what BFA is, take a look at the picture in this post. Why is this better? Well, here are 5 reasons why I think analysing barrier failures is better than 5-why.

1. Barriers focus your attention

In a 5-why diagram, everything is an event or a root cause. If the incident is large, this can lead to an overwhelming amount of information with no difference between important and supporting events. In barrier failure analysis, events are scaffolding that allow us to identify barriers. Barriers are what the organisation should have had in place and it is where our focus should be. During the investigation this focus is useful to spend the resources we have in the right place. After the investigation is complete, this focus is also useful to communicate more effectively to people that weren't part of the investigation team.

2. There is a clear visual sequence of events

A 5-why diagram flows in one direction. Both the sequence of events and the contributing factors are all displayed from, for instance, left to right. Barrier failure diagrams flow in two directions. The events and barriers are modeled horizontally, and the barrier failure causations are vertical. This makes it easier to distinguish between the direct sequence of events in the incident and the underlying contributing factors.

This is not unique to barrier failure diagrams. For instance causal factors charting ^[1] also flows in two directions.

3. It's more difficult to stop the analysis too early

5-why gives little guidance beyond asking why and ending up with a root cause. This can lead to root causes which aren't useful root causes. The analysis can stop too early (e.g. 'warning signs were absent', without diving into why they were absent) or actually go too far (everything was 'poor safety culture'). In barrier failure analysis, this problem is reduced by giving each level in the causation path a specific purpose. You describe the immediate cause first, then the context in which that immediate cause can happen, and finally the underlying system level cause. In 5-why, the 5 levels don't have a meaning (except for the final one), which makes it more difficult for people to guide their analysis in the right direction.

4. Recommendations can focus on immediate and long term interventions

There are two logical places in a barrier failure analysis where recommendations can be made. On the barrier for more immediate corrective actions, and on the underlying cause for a more long term systematic intervention. Both are useful because we can first get up and running safely in the short term, and then prevent recurrence in the long term. The recommendations in 5-why usually focus more exclusively on root causes, and thus on the long term only.

5. It's easier to connect to existing risk assessments

Any risk assessment method you use already has the concept of barriers (control measures, IPL's, safeguards or something similar). It's weird to have different ways of thinking for incident analysis and risk assessment when they are really two sides of the same coin. With a barrier-based incident analysis method you can more easily connect back to the barriers in an existing risk assessment. This can be useful for trending across incidents and to add new incident scenarios to the risk assessments.

If you want to know more about barrier failure analysis, we have a great course on incident analysis with barriers on 5-6 June in Leidschendam, The Netherlands. Go to slicerisk.com or view the brochure

One of the assumptions in a bowtie diagram is that all threats cause the top event, and the top event can cause all consequences. This is the theory. But sometimes a threat can't lead to all consequences. Why is that and is it a problem? We'll see why it's not necessarily bad, but it can be if you don't realise that you're doing it.

Let's start with a confined space entry example.

As you can see, a lack of oxygen leads to an unsafe work environment, which leads to asphyxiation. Excessive heat also leads to an unsafe work environment, which leads to heat stroke. But a lack of oxygen cannot lead to heat stroke and excessive heat cannot lead to asphyxiation. How did we get to this situation?

This picture summarises what happens:

The trick is in the top event, because there is a difference in abstraction level between the threats/consequences and the top event. We are adding specific threats and consequences to a high level top event. It is very common in bowties to see this pattern.

Let's first discuss the alternatives to fix it, and then get back to whether it's a problem for our confined space bowtie. There are two ways to fix it. Either we make our top event specific, or we make our threats and consequences more abstract. If we make our top event more specific, you'll see that your bowtie breaks apart into smaller sub bowties, like this:

Now all threats lead to all consequences in both bowties. The pros of this approach is that we have specific information in our bowtie, and the causality is correct again. The downside is that we now have one extra diagram, and in reality it might break apart into even more bowties.

We can also make the threats and consequences more high level. That would result in something like this:

You will probably group multiple specific threats and consequences into higher level subjects. The pros of this approach is that we get to keep our single bowtie diagram, and also maintain a correct causal diagram. The downside is that we lose some of our specific information.

Now we can go back to our confined space entry bowtie and determine if we want to split it into two bowties, with one top event called 'Oxygen level below X' and 'Heat in confined space above X degrees celsius' or if we want to create a high level bowtie and group our various threats into 'Environmental factors' and our consequences into 'Adverse effect on person'.

You can probably see that both are not ideal. But what about a third option. Let's say we keep our original bowtie. This means we get to keep our single bowtie, as well as the specific information in the threats and consequences. The downside is that the causality isn't technically correct anymore. But after reading this post, the big difference is that you're now aware of it, and you can make a conscious decision whether the benefits outweigh the disadvantages.

One last note. You can make the decision which of the three strategies works best for you when you're using the bowtie as a qualitative communication tool. If you're using it in a quantitative way. You'll most likely want to make multiple specific bowties, because you need a correct causal relationship for most calculations to make sense, and you need specific information because it's difficult to quantify abstract concepts.

Many organisations have adopted, or want to adopt, the idea of barrier management in safety ^[1]. Many are also searching for ways to take a next step. The barrier maturity model is a simple way to first determine where your organisation currently stands and then see which steps can be taken to mature to a higher level of barrier management.

The barrier maturity model has four main levels

1. Pre barrier level
2. Static barrier level
3. Dynamic barrier level
4. Operational barrier level

Each level represents a different type of maturity in an organisation. The levels do not necessarily follow each other in a linear way but in an effective barrier-based risk management system, all levels should be present. Especially the dynamic and operational level tend to work together. It is useful to have these levels because it allows us to discuss how we can transition to a next level to further adopt and integrate barrier management into the way of thinking and dealing with safety.

Pre barrier level

The current approach for many organisations is to focus on risk matrices instead of barrier management. This is the case in more traditional approaches using an excel sheet with a single column describing barriers (or control measures). The main point of the sheet is to show that the inherent risk level has been brought down to an acceptable residual risk. This is of course useful, but the barriers do not have a central role and are not fleshed out in much detail.

How to progress

To get to the next level, a model has to be chosen which puts more emphasis on analysing the barriers in a structured way. We typically use a bowtie diagram for this purpose, but you can choose a different model if you prefer. As long as it allows you to analyse which barriers you need and how you plan to maintain them.

Static barrier level

Most organisations that work with barrier management are at this level. Risk scenarios and associated barriers are analysed in a structured way. This helps to identify high risk areas where improvements should be made. It then results in an improvement plan which is the primary outcome of the analysis. However, often the reports themselves are shelved and nobody looks at them again until the next risk review. The problem is that this is not a continuous process but merely a snapshot at the time of the analysis. A report is made and hopefully communicated to the right stakeholders, but the analysis is not used for anything more.

How to progress

The main problem is not the analysis itself, it's that no data is connected to show the current status of the barriers. Why would someone look at a model if the information it provides is always the same? To move to a more dynamic view, an overview of the available data related to the barriers has to be made. This can then be connected.

Dynamic barrier level

Some organisations are actively monitoring the performance of their barriers over time. This is done through various data sources. Incidents and audits are commonly used, but the maintenance system, competence management, permit to work or sensors can all provide valuable data that can be mapped onto barriers.

How to progress

The challenge to get to the highest level of barrier maturity is to package the dynamic information in the right way to aid decision-making. This can be in the operation, as well as on a corporate level.

Get an overview of who needs to make which decisions, and what type of information they need to help make that decision. If you are working in a high risk environment, what type of information would help you make a risk critical decision?

Operational barrier level

Organisations should provide the right barrier information at the right time to the right person to make the right decision. This is the final stage of the barrier maturity model. To achieve this, talk to people in high risk departments. Understand what their daily routine looks like and how this routine can be enhanced by providing timely barrier (performance) information. The main challenge is to fit this information in so it adds maximum value and a minimum of extra workload. The result might look very different from the original barrier analysis, but that's ok. That just means you put in the effort to transform the information into something useful.

Few organisations have reached this level of maturity. We think the main reason is not a technical issue. It's often difficult for people to understand what is needed by other people that have a different role in the organisation. Instead, assumptions are made about what would be useful which don't match with reality. To understand what is needed requires a high level of trust, cooperation and communication that is often lacking.

Conclusion

The barrier maturity model is a roadmap that can be followed by organisations that want to take the next step in barrier management. It's of course possible to take a different route, for instance to communicate static barrier information to the operation directly. This can even make it easier to mature barrier management, because you can have results sooner and keep the momentum going. However, to fully implement barrier management it's necessary to eventually go through all four levels. There is more to say on the details of each level and the path that can be taken to go from one level to the next, but we will write more on this in future articles. Stay tuned!

Photo by Gabriel Jimenez on Unsplash

The hierarchy of control is often used as a brainstorming tool to come up with effective controls (aka, barriers). It's good because it favours proactive interventions like eliminating a source of fuel over reactive interventions like putting out a fire. However sometimes it is misused as a formal classification tool. This is bad because it mixes two different subjects. Control functions and control systems.

For example, substituting a dangerous chemical can be done by mixing it with a second chemical. This might require a worker to mix in the second chemical. Is this a substitution control or an administrative control? If it's used as a brainstorming tool this doesn't really matter. But for control classification this overlap is ugly and can lead to lengthy discussions.

Another example: Is an airbag in a car an engineering control? After all, it is a fully automated system that functions independently of the worker. It's installed or purchased early on. In a way it isolates the driver from the energy of a crash. On the other hand, I can also argue it's PPE because its sole purpose is to protect you personally.

Ok, last one: If you regard working at height a hazard, monitoring weather conditions might cause cancellation of the work before it begins. Is this an elimination control or an administrative control? Part of the problem in this example is how we define a hazard. Traditionally a hazard is often a substance like oil or a chemical. But if an activity like working at height can also be a hazard, what does it mean to eliminate? Should elimination be permanent or can it be temporary by postponing work?

So hopefully you see there might be some discussion when this is used as a classification tool. Now let's move on to the alternative. Enter the difference between functions and systems. Functions are what we want to achieve (eliminate, substitute, prevent, mitigate). Systems are the means by which we achieve that function (engineering, administration). If you take nothing else from this post, at least consider the difference between these two things. PPE is not in these lists because I consider it a specific type of equipment on a different level than the other categories. We will not discuss PPE specifically further.

As an example, here is an alternative classification system that uses two aspects for each control. A function and a system category.

Control Function

The control functions are based on the 10 strategies by William Haddon. A lot of the existing classifications seem to be based on his work, and so is this one.

The first thing we consider is if we need to accept the existence of a hazard. This is the elimination step in the hierarchy of control. The three functions we want to achieve in relation to the hazard are to:

Eliminate the hazard
Substitute the hazard
Reduce the amount of hazard

If we cannot eliminate, substitute or reduce, we have to focus on keeping the hazard under control. The first thing we try is to:

Control deviations. Deviation events are possible because we let the hazard exist. Some more specific functions that might be relevant for some deviations are to 1. Eliminate the event, 2. Reduce the size of the event, 3. Modify the event rate or 4. Change the event properties.

If we cannot stop the deviation event, we have to keep it away from objects we care about. Objects is an abstract term in this case which usually refers to people, assets, environment or reputation. So now we try to:

Separate the deviation event in time, space and access from the objects. If we cannot control the deviation or separate it from the objects, we have to:

Protect objects. The difference here is that the deviation can run its course. We do not necessarily know what the specific deviation will be, but we create controls that will best protect an object from a range of possible deviations. If all else fails, we must also consider how to:

Reduce damage to objects. Here we try to reduce damage while the deviation is still ongoing. Then finally, after the deviation has passed, we can:

Stabilize, repair, and rehabilitate objects

Control System

Control systems are the ways in which we achieve our functions. At a high level there are two types: physical systems or behavioural systems (i.e. engineering or administration). The following splits those two up into more subtle categories and is an adaptation of the barrier classification in ARAMIS.

Behavioural. A system reliant on only people and procedures. E.g. a double check, defensive driving.
Active hardware. A physical system built from equipment which does not require human interaction for it's primary function, although it does need to be maintained by someone. On some input, the system takes an action.
Socio-technical. A system that needs both a person and a piece of equipment to perform it's primary function. E.g. emergency shutdown system, confined space continuous monitoring.
Continuous hardware. A physical system that needs energy to function, but instead of waiting on input to take action, the action it takes is continuous. E.g. ventilation, active corrosion protection.
Passive hardware. A physical system that does not need energy to function, and also doesn't take action. E.g. walls, fences, paint.

Conclusion

These two lists for function and system are just examples of possible categories. Let's take a look at the three controls we had above and see if we can classify them.

Perhaps brainstorming controls is easier using the hierarchy of control directly because you only have to consider one list. But after the brainstorming, when you want to put a barrier in a category, please consider splitting function and system.

After an incident has occurred, most investigations will try to find the root cause on a system or management level. To find the underlying reasons for an incident, instead of focusing on the more superficial ones.

An important reason for doing this is the assumption that by fixing a single root cause, we're not only fixing the incident at hand, but also many related incidents. This gets us the maximum bang for our buck. But is this a correct assumption?

If something sounds easy, it's generally incomplete. Root causes are no exception. What single thing can you fix that will have far reaching effects? Maintenance? Leadership? Culture? Whatever comes to mind will likely fall apart into many small, albeit related, things. For instance, fixing a maintenance management system likely includes fixing a lot of specific maintenance procedures, educating individuals, redesigning work environments etc.

At best, root causes are a way to group a list of specific issues.

Why can't we identify just one specific issue to fix on a system level that will prevent multiple incidents? Because preventing different incidents is done by fixing many specific issues, not just one.

Does this mean we have to abandon our search for root causes? Probably not. It's still good to look for improvements on a system level to avoid symptomatic fixes, but there are two things that come to mind. First, finding a single root cause to fix is more work than it sounds as it breaks apart into many specific tasks. Second, in some cases, it might be better to spend all that effort at the sharp end, fixing specific things there, instead of that 'one root cause' far away. Because if that one cause doesn't exist, it becomes possible that we get the biggest bang for our buck, not by fixing a lot of specific system issues, but a lot of specific operational issues instead.

Image by Tor Lindstrand