"Pipeline process management includes determination of needs throughout the pipeline life-cycle, provision of sufficient human and financial resources, identification of the proper sequence of a series of activities, monitoring and measuring the effectiveness of the activities performed, and applying changes or corrections to those activities as needed. "
– API RP 1173 Managing the Safety of Complex Processes
API RP 1173 is a recommended practice introduced by the American Petroleum Institute that defines requirements for a holistic approach to pipeline safety. Companies that adopt these requirements can improve their safety efforts and achieve greater levels of safety performance. To accomplish this, companies must first define their obligations before they can successfully implement their pipeline safety system.
The goal for API RP 1173 is not to implement all aspects of the practice but rather to use it as a framework on which to build or review a safety program to determine how better to achieve safety objectives (i.e. zero incidents). There are several aspects of this framework that makes a traditional check-box approach to compliance ineffective. In fact, it is the wrong way to look at applying this practice.
Here are three key characteristics of API RP 1173 that companies should keep in mind:
1. API RP 1173 is a recommended practice
API RP 1173 requirements are not mandatory nor are they the full extent of what a pipeline safety program should do. Each company needs to determine what they want their safety program to accomplish and to what extent API RP 1173 will be used and if other practices or standards should also be adopted.
"In all cases, operators are intended to have the flexibility to apply this RP as appropriate to their specific circumstances"
– API RP 1173
2. API RP 1173 is performance-based
API RP 1173 is not prescriptive in terms of how requirements should be met and in some cases what needs to be accomplished. At a minimum, it is up to each company to determine the "how" necessary to achieve the goals and objectives of their pipeline safety program. As the practice is a framework, each implementation may look different in the details from one company to the next.
Several of the approaches I have seen use a gap analysis as part of the implementation process. This is common particularly when dealing with prescriptive standards. However, API RP 1173 is not prescriptive so it creates a challenge for those that are looking for a simple check-box approach to compliance. This may result in adding prescriptive requirements so that there is something to be assessed. While prescription may be necessary, there can and often is a significant difference between what is prescribed and the obligations themselves. They are not one and the same.
Instead, companies need to separate the "ends" from the "means" with their implementations. This distinction is critical and affects how audits should be conducted to assess compliance. It is common for performance-based standards to separate those things that verify the means from those that validate the ends (i.e. outcomes). An effective safety program will do both.
3. API RP 1173 is risk-based
Safety programs are often described as being all about risk reduction and you could say the same about API RP 1173. However, it also means using a risk-based approach to achieving safety outcomes given that there are limited funds, resources, and time to accomplish the goals.
Tailoring the means by which safety is done while at the same time coordinating efforts to address systemic risk is one of the hallmarks of API RP 1173. Using a risk-based approach to identify the extent of this tailoring is an effective strategy that is gaining traction as better way to establish compliance objectives.
Build your safety program on obligations instead of requirements
All of the reasons previously stated contribute to why it is first necessary for companies to identify and define their obligations. This will help ensure that appropriate levels of effort are directed to meeting each obligation. In addition, it allows the means by which they are met to improve and mature over time which is recommended by API RP 1173.
The following steps are well suited for companies who are looking to establish their API RP 1173 compliance obligations:
Document the context and expectations for each obligation
Define what constitutes evidence of compliance
Define how progress against outcomes will be measured
Identify what standard will be used to establish normative processes (ex. ISO 9001:2015, ISO 31000, internally defined, etc.)
Identify what is needed (structure, resources, technology, culture, etc.) by the organization to achieve the desired outcomes
Identify and evaluate risks (both threats and opportunities) for each obligation
Embed obligations, controls, and risk treatment into compliance programs, systems and processes
The output from these steps can be used as input to create a compliance map to help steer the API RP 1173 program.
Instead of the typical compliance map that looks like this:
you will end up with an obligations-based compliance map that looks like this:
This may appear to be a subtle and insignificant difference in approaches, however, this is far from the truth.
An obligation-based compliance map is focused on identifying and meeting obligations. These are commitments that management makes and it is these commitments that are used to determine the means by which outcomes are achieved.
Compliance is built into the means and verified through measures of: effectiveness (MoE), compliance (MoC), and performance (MoP). This affords companies the ability to be certain of their compliance and their capacity to always stay in compliance.
Whereas, the previous approach is a remnant of prescriptive-based compliance focused on audits where for the most part documents and records substitute for evidence of compliance. It is well understood (yet not often heeded) that you can have a documented procedure that is not being followed or is ineffective at achieving the outcomes of the program. The only thing you do know is that you met the requirement to have a procedure and this is the crux of the matter.
Compliance to prescriptive requirements while important is no substitute for programs that continually advance compliance outcome by maturing capabilities.
