Safety performance is improved when organizations take a comprehensive and systemic view of their safety efforts. This requires different skills than implementing separate activities connected with requirements where the "means" have already been specified.
With todays performance and outcome-based regulatory designs, organizations must now identify and determine how they will achieve targeted safety goals; which can be considered as obligations.
A "design" step is needed to translate requirements to design specifications. These specifications describe the ends (key results and objectives) and the means (people, process, technology) of the safety effort needed to meet your obligations.
API RP 1173 Management of Change (MOC) Example
The following completed system requirements canvas demonstrates how this looks like for a Management of Change (MOC) sub-system for a Pipeline Safety Managment System (SMS) using API RP 1173. Although, this approach can be applied to other types of systems where improvement in both performance and outcomes have been targeted.
This canvas maps requirements to the processes and capabilities that have been identified to achieve MOC effectiveness. Since API RP 1173 is a recommended practice (i.e. not mandatory) and uses a performance-based approach, it is no surprise that elements only include minimum procedural requirements that could be verified using an internal or external audit. Although, no certification body exists or is expected.
When considering requirements a necessary (and perhaps the first) step is to identify what effectiveness looks like. This goes beyond looking at minimum prescriptive requirements and includes consideration of the system's overall purpose, internal and external dependencies and requirements that come from improving essential capabilities to achieve key results and objectives.
For an MOC subsystem, effectiveness can be defined as:
Management of change is effective when it keeps pipeline safety risk (individual and aggregate) within acceptable risk levels (risk tolerance) resulting from technical, physical, procedural or organizational change.
This measure of effectiveness will create additional requirements although not specified in API RP 1173, are certainly expected as part of its adoption.
A comprehensive design will also consider overall system properties which for a purposively system, like a Pipeline SMS, can be expressed in the following way:
The first property we have already addressed, although not for the system as a whole.
We know from system theory that a system is not the sum of its parts and is rather the product of its interactions. We expect that all subsystems will be designed to contribute to the production of the essential system properties. Therefore, we must identify what is needed for the MOC subsystem itself and its contribution to the whole (i.e. dependency requirements) with respect to being: effective, proactive, viable, sustainable, resilient, efficient, adaptive, and transparent.
A design structure matrix (as shown below) can be used to identify dependency requirements along with possible vulnerabilities or gaps in system capabilities:
Summary
To meet performance and outcome-based obligations each organization must establish their own goals and objectives along with the means by which they will be achieved. It is in meeting these obligations that create performance requirements that extend beyond procedural specifications within the API RP 1173 framework as in our MOC example.
A design step is now needed to translate performance, element, and system requirements to design specifications for solutions that advance overall outcomes. As safety is an emergent property of an overall safety system the design step requires knowledge and skills in system design, cybernetic controls, and risk-based strategies to ensure that safety is advanced. These are not only needed for adopting API RP 1173 but for all performance and outcome-based regulations and standards.
