The topic of what is essential is on the minds of many individuals, organizations, and governments certainly with respect to navigating the COVID-19 pandemic.
Over the last several weeks we have seen governments mandate shutdowns and/or lock-downs of non-essential businesses and services, along with public movements and transportation as part of the #StayAtHome measures.
All of these actions are intended to fight the corona virus but all of them have an impact that goes beyond COVID-19.
One surprising impact is that it is causing many to reflect on what is essential for their life, their business, their jobs, and for their communities in which they live.
There is nothing like a good crisis to help prioritize what is important and what is not. When the game changes so do the rules and strategies that go along with it.
As an example, In recent weeks, as many of you might know, the Environmental Protection Agency (EPA) decided to suspend its enforcement of environmental laws signalling to companies that they would not need to meet environmental standards and regulations during the corona virus outbreak. This was done in recognition that (in their words) companies might better use their resources to ensure their pollution control equipment remains up and running and the facilities are operating safely, than to carry out routine sampling and reporting.
PHMSA's Pipeline Safety Program has also issued a stay of enforcement to state pipeline safety program managers, pipeline operators, and operators of gas storage and liquefied natural gas facilities. The agency has temporarily halted its enforcement of compliance with operator qualification, control room management, and employment drug testing requirements, but has not relieved operators of their safety responsibility to use trained, non-impaired workers to perform operation and maintenance tasks. PHMSA also encourages state pipeline safety partners to consider suspending certain enforcement efforts for noncompliance in the interest of prompt and efficient pipeline safety activities related to the effects of the COVID-19 outbreak.
If these actions means anything, they means this ... that inspection, reporting, and enforcement are not essential to environmental as well as pipeline safety. You could, and we will ask the question, "if these things are not essential, then what is?"
Finding an Answer
That is the question that I want us to consider now.
“What are the essential properties of a pipeline safety management system?”
If we didn’t focus on such things as certification, audits, and enforcement. If instead we focused on something else, what would our systems look like?
For our discussion today, we will use as a reference API RP 1173, although what we will be talking about also applies to the Canadian standard CSA Z662.
And before we dive in, I know that many of you are already thinking, doesn’t 1173 already define what is essential when it talks about the elements contained in the guideline? Well, yes, and no.
Let me explain.
When we think of the question in front of us some might answer it by counting the number of shall statements in API RP 1173 guideline.
I know that some of you have done this. Hands up if you have!
The word “shall” is used over 150 times in the context of what the guideline considers as mandatory requirements which one might think are good candidates for what is essential. But, essential for what?
As a point of interest, and maybe more, we all know that API RP 1173 is a voluntary guideline, albeit, strongly encouraged but voluntary just the same. The reason for raising this point is that some might come to conclusion that the number of mandatory requirements might be closer to zero rather than 150. I don’t think you would be wrong if you thought this. API RP 1173 is voluntary so there is technically speaking nothing mandatory about it.
Perhaps, this is splitting hairs, but maybe not. When it comes to deciding what is mandatory depends on what you are trying to accomplish. If the goal is, let’s say certification, then perhaps you will end up with a number that might be closer to 150 than zero. But again I will ask, are these essential?
Let me ask the question another way.
How many requirements and which ones must be met for a pipeline SMS to be effective, to be operational?
You might answer this one differently which most will agree would produce a better answer but maybe not the best answer.
For that we need to ask yet another question.
What properties (you could also say behaviors, or better capabilities) must be present for a pipeline safety management system to be effective?
I propose that it is the establishment of these properties that define what is really “essential” not for the purpose of certification, or to pass an audit, but rather to fulfil the purpose of a Pipeline SMS which is according to API RP 1173 is:
“to enhance effectiveness of risk management and enable continual improvement of pipeline safety performance…ultimately to achieve the goal of zero incidents”
Answering this will give you a different set of requirements. And here’s the kicker. These are already stated in API RP 1173, but they are not listed as mandatory requirements connected with shall statements, and so they are mostly overlooked, but not today.
Every Purposeful System Has Essential Parts
We will look at these in some detail in a few moments. However, right now, I want to unpack our question further by means of an example and by analogy.
I will use an example of a car which is familiar to most.
A car is not a safety system but is instead a transportation system not too unlike transportation systems we use to move hazardous liquids and gases.
A car is a system made up of various components with the purpose of transporting people (mostly) from one location to another.
A car is effective when it performs its purpose which in this case is transporting people from point a to point b. If it doesn't do that then we don't really have a car we don't have a transportation system.
There is a person by the name of Dr. Russell Ackoff, a contemporary of Edward Deming, both of who were considered as thought leaders in the space of systems-thinking. Although more familiar in the context of quality, their contributions have impacted the way we think about systems in many other domains including safety.
Russell Ackoff defines a system in the following way and this is important:
“A system is a whole which is defined by its function in a larger system of which it’s a part”
Using our example of a car which is a system defined by its function of transportation; that’s its purpose. It is part of a larger system which is you could say is a larger transportation system that includes highways, roads, and so on.
Ackoff continues with his definition:
“For a system to perform its function it has essential parts”
These are parts that if they do not exist prevent the system from performing its function.
Nothing surprising here, but wait there's more.
Non-purposeful Systems Only Have Parts
“System properties are derived out of the interaction of its parts and not the action of its parts taken separately”
It is the collective interactions of all essential parts that are responsible for the overall system behavior. Transportation is an emergent property of a car when all the essential parts work together. It is not the property of any of its parts taken separately.
When you take a car apart it is no longer a car. It cannot perform its function. You can take all the parts and put them on the ground. You can analyze them, improve them, but you still don’t have a car.
Some of you may now be getting the idea of where I am going when it comes to safety systems.. but hang on .. where almost there.
There are also no parts on their own that can perform the function of a car. For example, a car engine, by itself cannot transport anything including itself.
Another way of saying all this is a system is not the sum of its parts. In fact, a system is a product of the interaction of its parts. Without the interactions you only have a bin of parts, a collection of components, a set of elements, but you do not have a system.
In the case of a car the emergent property of transportation is never realized. And when this is applied to Pipeline Safety Management Systems the emergent property of safety (or protection if you like) is also never realized.
A Common But Ineffective Approach
I am now going to make a statement which may be surprising to some, but here it is:
Many (perhaps most) organizations when it comes to pipeline safety implement only the parts and not the necessary interactions. They are failing to establish the essential properties necessary to advance overall pipeline safety performance. At most they are advancing their bin of parts or relabeling what they already have, but they have not advanced their safety system.
We can see this by the use of a common approach for implementing API RP 1173 which is to divide-and conquer by focusing on the elements and shall statements, which is understandable for a variety of reasons, but ineffective nonetheless.
Let me explain why.
The RP 1173 guideline is structured as management system standard similar to ISO standards and some regulatory frameworks, but with important differences.
First, it is not a prescriptive standard, intended to be audited. It is a performance standard to be used as an evaluation framework for companies to improve overall pipeline safety performance.
Although, as many should already know, the guideline is presented as a collection of essential elements (10 in total) with language that is compatible with prescriptive standards that utilize audits and certifications. You will find, “shall standards” contained in and across all 10 elements:
Leadership and Management Commitment
Stakeholder Engagement
Risk Management
Operational Controls
Incident Investigation, Evaluation and Lessons Learned
Safety Assurance
Management Review and Continuous Improvement
Emergency Preparedness and Response
Competence, Awareness and Training
Documentation and Record Keeping
You will see the same thing for CSA Z662. But this is not a signal for how the guideline should be implemented.
The shall statements afford some measure of support for an audit function, but not the safety performance improvement function, and therein lies the rub.
A Bin of Parts
When following an element-first approach you will end up with is a collection of parts which can be tested to see if they are present, and thus supports some degree of verification.
However, you do not end up with an operational system that is effective at improving safety performance. For that you need another approach and another set of requirements.
An Operational System
To have an effective system it is necessary to focus on system properties with the goal of having all essential parts working together as a whole.
Doing so will result in an operational system that will improve safety performance over time and advance outcomes making progress towards zero incidents (the ultimate purpose of API RP 1173).
And when you do this the implementation will look different than the other.
API RP 1173 Essential Requirements
API RP 1173 tells us what system requirements are essential but does not specify how these are to be done.
These are summarized in the section called, “Managing Safety of Complex Processes” although you will find others throughout the document.
These are all properties or capabilities that are essential to improve safety performance. They all speak to the system as a whole and about interactions. However, there are no shall statements, no prescriptions.
The "how" part of system requirements needs to be defined by each company based on their own level of risk, organizational structures, and specific goals and objectives. These are more difficult to audit or to certify against. However, and here's the thing, without capabilities to support system level interactions you do not have a system. All you have is a collection of individual and separate elements.
Not defining the "how" is normal for a performance-based guideline, but not normal for those that have for years focused only on prescriptive and legal compliance obligations, and that is why we need to as an industry do more to educate organizations on "how" to do this.
What is Essential Depends on Desired Outcomes
When implementing API RP 1173 some have have focused on the shall statements anticipating that
certification may be required at a future date, and/or
it’s a place to start which they will improve on later.
However for that to happen you need an operational system that has essential behaviors, perhaps not at the performance levels you ultimately need, to be a platform on which to measure, learn, and improve your safety performance over time.
Using our example of a car, you cannot achieve better transportation capabilities by reorganizing your stock room of parts, or by adding or removing parts.
If you can’t build a car, you at least need a motorcycle or a bicycle as a starting point not a stock room of parts.
And given that API RP 1173 is a voluntary guideline anyways I see no reason why organizations should not focus on what is essential rather than what will pass a possible audit.
Essential Properties For an Effective Pipeline Safety Program
Effective Pipeline Safety programs are those that are:
Operational – they must have all the essential parts working together as a whole to produce an emergent property of safety evidenced by the achieving and advancing safety outcomes. Capabilities (people, process, and technology) are sufficient to ensure that the system is more than the sum of its parts, and instead is product of the interactions its parts.
Proactive – new goals and measures are established that continually advance outcomes. Feed-forward controls are used to prevent or mitigate the effects of uncertainty and the ensure the advancement of outcomes. Continuous improvement is applied to both outcomes and performance.
Viable - can be achieved using current technologies.
Sustainable – capable of consistently achieving targeted levels.
Resilient – consistently performs in the presence of changing conditions. Feed-back controls are used to reduce variation and to create consistency in both performance and outcomes.
Efficient – achieves targeted performance with minimum waste.
Adaptive – learns from the past to improve future outcomes. Performance and outcomes are measured to understand correlation and causation.
Transparent – capable of retrospective investigation and analysis. Measures of effectiveness, performance, and conformance are continually measured, monitored, and shared to steer the system towards its ultimate goal of zero incidents.
Systems that have these properties in increasing measures of capability maturity are more likely to advance safety goals, provide greater confidence (i.e. assurance) that safety outcomes can be achieved in the future, and create a culture where safety is valued.
