Making the case for safety in the face of ambiguity
an hour ago
5 min read
0
1
0
What is the collective noun is for a group of engineers? A solution, a tolerance, an alternative load path? I’m supporting the Institution of Structural Engineers on guidance for assessing risk in existing buildings and also contributing to the Institution of Mechanical Engineers’ ALARP working group. I haven’t been surrounded by this many engineers since my days flying helicopters and most conversations back then were one sided discussions about which part of the ageing Lynx was being held together by gorilla tape and a prayer that day.
Both institutions are doing important work to help their members make sense of what All Reasonable Steps and ALARP mean in practice. In support of this work, I am borrowing from my experience in aviation risk management to give a broader viewpoint beyond the Institutions’ membership.
You’d be forgiven for thinking that risk management in aviation is very different to buildings but the principles are the same. In fact, many aircraft are bought “pre-loved”, with incomplete and missing documentation; a position that many PAPs now find themselves in because much of the UK building stock is old, modified and undocumented.
This lack of information makes building safety professionals’ jobs harder because accident prevention is about identifying weaknesses in systems - risk is a function of what is not known about a system. Looking at the example of the 737 Max accidents, the risk was not just related to the trim system but stemmed from unknown (or uncommunicated) aspects of its behaviour.[1] Therefore, we must seek to minimise the unknowns, which is challenging without detailed information.
So how can we manage this ambiguity?
Using the information available, there are a series of steps that can help us develop the argument for safety:
· System definition
· HAZID
· Understanding the controls
· Structured safety arguments
· Accountability
System definition
Before any meaningful hazard identification exercise can take place, we first need to define the system[2]. For a higher-risk building, system definition means getting as clear a picture as possible of how the structure was originally intended to perform and how it might have changed. This includes understanding the design codes in place at the time of construction, the fire safety strategies, cladding systems, the materials and construction methods used and any installed systems such as smoke control or sprinklers. The better the system is defined, the more focused and productive the HAZID will be.
I recognise there is a need within the UK to gather more information about our building stock. Buildings don’t come with black boxes and many won’t give up their secrets easily but the more we collectively know about our buildings and their behaviour in certain situations, the more we can understand and share information about the risks.
HAZID
HAZID is essentially a guided brainstorming session, designed to uncover what could go wrong before it does, using causal and consequence analyses:
What caused previous incidents — and how do we stop them happening again?
What hazards exist in everyday operations — how can we reduce their likelihood and impact?
So what might a HAZID for buildings look like?
Once we have defined the system, prompts (guidewords) focus the discussion on possible hazards. In aviation, these might include pressure, vibration or fatigue. In the structural context, we might think of words such as:
Height – unusual geometry or very tall
Loads – live, dead, dynamic or transferred
Modification – undocumented changes, cut beams, removed walls
Age – outdated designs, untested materials
Corrosion, deformation, vibration, carbonation…and many moreTop of FormBottom of Form
In a workshop, a team can use these words to build a risk picture, even in the absence of perfect documentation. It’s a way to think laterally and ask “What might we have missed? Where are we making assumptions? Have we captured all reasonably foreseeable risks?”
Reasonable Foreseeability
Seeing as I have just opened that can of worms, I want to briefly touch on reasonable foreseeability because it ties into HAZID. It is an important concept to engineers because it determines whether a Hazard will need to be addressed. The IMechE’s “ALARP for Engineers”[3] states “the [hazard] analysis must be proportionate to the nature and complexity of the situation and the severity of its effects, if it is to identify all Reasonably Foreseeable Hazards.”
For building safety professionals, understanding what is reasonably foreseeable is essential when preparing a safety case. Using the Grenfell Tower tragedy as an example, we could ask was the consequence, scenario, failure mode or cause reasonably foreseeable?
Consequence
Was a catastrophic fire in a high-rise residential building reasonably foreseeable?
Scenario
Was a kitchen fire leading to external cladding ignition a reasonably foreseeable chain of events?
Failure Mode
Was vertical fire spread via the external wall system a reasonably foreseeable failure mode?
Cause
Were regulatory failure, poor product testing and miscommunication of risk reasonably foreseeable causes?
Understanding what is reasonably foreseeable isn’t just a legal question, it’s a practical guide to where your attention should go. As a Building Safety Manager or Accountable Person, you don’t need to eliminate every hazard but you do need to demonstrate that you’ve actively considered known hazards, asked the right questions and taken all reasonable steps in response.
Understanding controls
I am a fan of the bowtie model, largely because it encourages users to think in terms of control suitability and effectiveness, rather than simple likelihood and severity assessments.
The HSE’s document RR1170, High Rise Residential Buildings: Preliminary Serious Incident Scenarios and Potential Control Measures suggests we should give greater focus to the management of severe negative consequences, rather than spend time making subjective assessments of their likelihood. The authors state that with infrequent events it is inherently challenging to accurately assess the likelihood of them occurring, which is a major reason for using a safety case rather than a more typical risk assessment approach.[4]
A barrier-based approach leads the risk assessor to consider the possible threats (or causes) and how exposed, or vulnerable, the system is to each threat. The more robust the barriers/controls in place, the less vulnerable the system is.
Barrier management is directly linked to the SMS; being able to provide evidence of the barrier’s effectiveness and knowing that it will perform as expected, when needed, is crucial.
Structured safety arguments
When it comes to structural safety assessments, engineers are being asked to make judgments about existing structures that may not have been built as designed, have been altered repeatedly, lack drawings or clear structural logic.
This is where the Well-Reasoned Argument, or safety case comes in, to form the basis of the safety demonstration.
The safety case should answer several basic questions, such as: Has a full understanding of the building been demonstrated? What assumptions have been made? What are the potential causes of failure? How effective are the risk controls in place? If additional steps have been discounted, what is the justification?
The safety case takes us from chasing binary answers to building well-evidenced, clear arguments about what is known, what isn’t and why certain decisions are justified.
Accountability
My final point is about leadership and accountability.
Accountability doesn’t mean having all the answers, it means leaders being willing to make and justify decisions, even in the face of uncertainty. It means everyone involved in the design, construction, operation and maintenance of a building having clear roles and responsibilities for its safety.
I have heard much talk about the need for an improved safety culture in the built environment and perhaps taking on practices from wider industry will facilitate this shift. Adoption of the risk based approach I have talked about here and a commitment to move beyond compliance will only happen within the context of a just culture, where strong leadership gives people the confidence to share what they know, from the good, the bad to the ambiguous.
[1] https://www.ntsb.gov/news/press-releases/Pages/NR20230124.aspx
[2] DEF STAN 00-056 (UK Ministry of Defence)This is one of the clearest sources that explicitly outlines “System Definition” as the first step in the system safety lifecycle. ISO 31000 / ISO 31010 (Risk Management Guidelines & Techniques).While broader in scope, these ISO standards recommend context definition as an early step.
[3] https://www.imeche.org/docs/default-source/1-oscar/reports-policy-statements-and-documents/alarp_report_2024-03_02.pdf?sfvrsn=63c04611_0
