BTI: Dressing up for Risk Assessments

I've been doing a lot of pondering on the Bow-Tie method of risk assessment for a project at work. Bow-Tie is a tool used by many, especially in the oil & gas industry, to create a picture of risk surrounding a central event. It's got a few positives and a few negatives but these can be overcome if you understand the limitations of the model being used.

The Basics

Let's stick to the high-level stuff here because the deeper you go, the murkier it gets. The names change depending on the source or software one uses but I think the overarching concepts remain the same. In short, don't shoot me if I use different names, hold your fire if I describe the concept differently, and fire away if you think I am way off track.

Bow-Tie is a graphical view of risk.

As stated above it centres on a central event - sometimes called the top event or hazardous event. On the left of the diagram are precursor items - sometimes called safety events, contributory factors or threats. While on the right, there are consequential items - often simply called consequences but may also be labelled outcomes, effects or losses. For this post, I'll use threats, top event and consequences as my standard terms.

On the lines connecting the threats, top event and consequences, you insert controls (or treatments, barriers, etc.) to address the risk. Those controls may be subject to defeating factors (or escalation factors or barrier decay factors, you get the picture) which seek to reduce the effectiveness of the control. You can insert more controls to address the defeating factor which may introduce more defeating factors and so on and so on.

Here's a pretty picture:

Bow-Tie Overview

The Model

The Bow-Tie is a selective picture of a risk scenario. It focusses one's attention on a top event which, I think, frees up the thought processes to identify the other aspects of the issue at hand and allow for better analysis of the scenario.

It contains an implicit consideration of time as it progresses generally from left to right but not in an overly restrictive way. Defeating factors fall outside this and can often be thought of as latent conditions of the Reason-esque variety, existing for an indeterminate amount of time before manifesting during the risk scenario - even after the top event.

Starting on the left, you have the precursors to the top event. Some might call these causes but that can be a dirty word in accident modelling. Usually, you can't really make a causal link between precursors and consequences especially in post-hoc accident investigations. That's why the term "contributory factors" tends to be favoured.

I favour the term threat. To me, it's a little more than a hazard. It's a specific manifestation of a hazard or more like a situation - it could be an event in its own right but often they are hard to track or discretely identify. I haven't really come up with succinct definition yet - these posts tend to be my incomplete thoughts "out-loud".

In the middle we have the top event. The selection of a top event can be tricky but it is typically a significant event which is easily identifiable with at least some occurrence data available. Historically, the top event has been characterised as the release of energy. I'm not convinced that this works in the aviation context. While we do have contained energy in various systems - fuel, hydraulics, the cabin environment, etc. - the essential operation of aircraft, i.e. flying, doesn't so much contain energy as it rides an enormous tsunami of potential and kinetic energy. I, sort of, touched on this when I posted about the inherently perilous nature of aviation.

To the right, you have the consequences - the things that happen after the top event. This area can be tricky as well but I'll talk more about that in a moment.

Once you've built your picture then it is time to start inserting your control measures on the connections between your threats, top event and consequences. There are plenty of ways of categorising these controls and I'll go through some of my thoughts on these in a subsequent post.

I think one of the best parts of the bow-tie model is the defeating factor. The inclusion of this level in the structural model really gets you to think about active and latent failures which occur further upstream from the top event. In most of the fairly simple bow-ties I've developed to date, I've had lots more defeating factors than direct threats. I'll also elaborate on this in a subsequent post - in the meantime, don't be afraid to identify lots of defeating factors.

That's the basic model. It sounds pretty good but there are limits. Of course, a model is a simplified version of reality. It's vital that users of this model understand those limitations - otherwise unsupported decisions could be made.

The Edge of the Bow-Tie World

I said above that a Bow-Tie is a selective picture. Once you identify the top event, you've essentially set your focus with things in the periphery falling out of frame.

Aviation is a complex, dynamic system. It can't be boiled down to one or a few diagrams. We tend to think about accidents as long chains or networks of events. While the defeating factor dimension helps model this, sometimes we need to consider contributory factors of contributory factors or consequences of consequences - but this can severely complicate the analysis of a Bow-Tie. Some software have allowed the linking of Bow-Ties but the implementations I have seen are fairly superficial.

I'm still searching for an approach or implementation that supports the higher level of complexity of the aviation system. One that would allow analysis to be carried out by mere mortals. The Bow-Tie model is a trade-off. Therefore, you still need a parent system to manage the transition from real-world to Bow-Tie model, if your purpose is risk management within the aviation sphere.

So, don't push the model beyond its limits. As I'll get into in a moment, you've selected a top event for a reason, your analysis should remain within the frame of direct relationships. The longer and more tenuous the connections between your threats, top event and consequences are, the weaker the picture becomes.

Keeping Focus with Direct Links

The Bow-Tie model is rather simplistic. It can't handle complex, multi-stage causal pathways which include a mixture of conditional and independent factors. If you need to do this sort of analysis you would be better off with a fault-tree or event-tree type of tool. As I said above, the focus of the Bow-Tie is set on the top event and its best to keep the links direct.

I have seen on some bow-ties a long list of threats, some of which are actually precursors to other threats. For example, most runway excursion bow-ties include an unstable approach threat but some also include common contributors to unstable approaches such as inappropriate vectoring or pilot distraction. If you want to analyse these things it would be better to create a second bow-tie centred on the unstable approach threat.

The same thing happens on the consequence side. An example on this side would be a bow-tie with collision, crash and death in the same list. These three things don't occur at the same distance (read: time) from the top event and they are not necessarily independent - the picture starts to get muddy.

I also have a general feeling that consequences like death and crash are not specific enough to actually assist in the analysis. That sometimes cited cliché, "there is only one cause of death - a lack of oxygen to the brain", tends to dissuade me from using it as a consequence. Usually, lots of things need to happen before someone dies.

I'll admit that it is hard to put together a succinct bow-tie diagram. We tend to have lots of things we want to get into the risk scenario but it is important to get the structure right. Otherwise the diagram can become confusing quickly.

In order to keep things on track, I've been using a little narrative trick to check the appropriateness of my threats and consequences. Essentially, I create a little story running along each line from threat to consequence. If the story makes sense with just the threat, top event and consequence then I think I'm on the money. If I need to elaborate or clarify something then I am probably off the mark.

Let's look at another pretty picture, this time a simple runway excursion bow-tie:

Simple Runway Excursion Bow-Tie Diagram

So after drawing this, I would go along each line and make up a little story. Something like:

The unstable approach lead to a runway excursion with the aircraft departing the runway strip.

That seems to work. The story is complete, succinct and centres on the top event. Yes, I could elaborate on the precursors to the unstable approach and what happened after the aircraft left the strip but if I did that, where would I have to stop? The power of the Bow-Tie is its simplicity but, remember, that comes at a price.

Let's try the next one:

Low visibility lead to a runway excursion with the aircraft crashing.

Well, its succinct in this form but I don't think its complete. I'd want to know how low visibility ended up as a runway excursion. Did the pilot line-up wrong? Did he fail to see an object on the runway? I'd also want to know how and where the aircraft crashed. Did it depart the runway strip? Did it fail structurally? Did it collide with something? And so on.

Therefore, I don't think that low visibility is a suitable threat and I don't think that aircraft crashes is a suitable consequence in this risk scenario.

The last one would be:

A braking system malfunction lead to a runway excursion with the aircraft re-entering the runway.

I think that is back on track.

This simple diagram is not perfect. I think the wording of the good threats and consequences could do with some more work. I might need to separate some of them into more specific direct threats and consequences. But that will be the topic of another post...

I've said a couple of times above that these are some incomplete thoughts on this subject. I would greatly appreciate your feedback, comments, ego-boosters, rants - anything. Thanks.

Edit: I just added a BTI to the title to tie it in with a follow-on post.