Process Safety Management or PSM, is all about managing process risks, so it would stand to reason that we need to manage changes since any change can pose significant risks both new and latent. If we follow the Occupation Safety and Health Administrations (OSHA) PSM regulation, we should be very familiar with the Management of Change or MOC element. However, the language of the regulation is unclear and ambiguous. This ambiguity, or lack of clarity in the regulatory language, is evident in the hundreds of PSM program MOC policies and procedures reviewed as part of PSM compliance audits and incident investigations. Analysis obtained from audits and incident investigations would indicate that industries handling highly hazardous materials have room for improvement to fully implement a robust management of change process. Continuous improvement of safety and health management systems, require that we continue to look at policies and procedures and make the necessary corrections and updates. The same process of review and updates should be applied to our MOC policy and procedures. The policy and procedures should give clear guidance on what changes need to be managed and how. Without good guiding documents, we are simply NOT managing change.

To better understand some of the gaps and areas of concern regarding change management, it is best to start with a look at the regulation language. The PSM regulation states in 1910.119(l)(1) “The employer shall establish and implement written procedures to manage changes (except for "replacements in kind") to process chemicals, technology, equipment, and procedures; and changes to facilities that affect a covered process.” Replacements in kind are the only exceptions to those changes that must be managed, but what is a replacement in kind? The regulation itself attempts to further define “replacement in kind” as “…a replacement which satisfies the design specification.” Unfortunately, the definition of replacement in kind does very little to actually help define replacement in kind, but rather just states that it “satisfies the design specification.” Design specifications can have different meanings to different people. As such, “satisfying” a design specification will have different meanings. For example, a piping specification within the same facility can vary depending on the engineering company that designed the facility, or the contractor that installed it. True, the specification can call out the same general materials such as 316L, but even 316L can vary in metal composition and yield strength depending on the origin of the materials or standards in which the material was certified, if at all. However, if we use the “satisfies the design specification” criteria, then most facilities would say if it were 316L before, and it is being replaced with 316L now, then it would be a replacement in kind. However, if the specification called for the piping to meet certain certifications, then parameters such as material composition and yield strength would become part of the design specification and would need to be verified prior to determining it was a replacement in kind. Another simple example is design specifications stay the same, but the model number changes. Model number changes typically mean that some parts have changed as well, but this would be missed if we considered design specifications only. These are just two examples of where we can go wrong by just focusing on “replacements in kind” without looking into exactly what that might mean or entail within our process. From this writer’s point of view, there are two important parts of a robust and effective management of change program. The first is to clearly understand of how a change is defined and effectively applying that definition throughout the organization. The second is the procedures used to manage the change itself. In Part 1, we will focus on defining what a change is. Part 2 will be some thoughts and ideas on how to manage change effectively. Part 3 will be putting it all together to allow for continuous improvement and inherently help teach and train your organization on how change management improves your organizations process safety.

In the introduction we discussed some pitfalls in how we define a “change”. This process determines what changes go through your formal change management process or protocol. A simple solution would be to require that “any change” be handled through a change management process and not be concerned if it was a replacement in kind or now. This would take out any ambiguity and would result in all changes following a well-defined change management process. The second-best option would be to have a very robust screening process to help drive the requesting or initiating person(s) to the right decision regarding replacement in kind or requiring a formal change process. The latter of these two options is the most popular in most organizations, with some slowly beginning to see the benefits of putting all changes through the change management process. An issue most cited with the second approach is that many organizations lack a robust screening process and simply ask if the change is a replacement in kind and leave it up to the user to make that determination. Others may take it little further and ask if the change involves changes to process chemicals, technology, equipment, procedures, and the maybe changes to their PSM organization. This approach may indeed meet the requirement, but when criteria are left to interpretation, catastrophic unintended results can and have occurred. Almost every change, even those we might think are replacements in kind, are almost never “in kind”, therefore, our MOC process should be driving us to fully explore the breadth and depth of the change, and address and document the change appropriately. At the same time, we do not want to make the MOC process so cumbersome that it promotes bypassing it to get things done! There is a fine line between making things so hard that people will avoid them, to making them too easy that they lack effectiveness. The most effective MOC process is one that is simple and easy, and that allows anyone in the organization request or initiate a change. The preference would be to take all changes through a robust change management process, if that is not an option, we need to create a simple yes/no checklist, a place to provide the technical basis for the change, estimated cost of the change, and a detailed description. Each question in the checklist is used to elicit a response that determines whether the proposed change is a replacement in kind, or it is a managed change. This then is the basis for approval(s) whether that is a single authorized approver or there are multiple approval levels. If approvers want more detail, then we provide this additional information in attachments. We do not want to spend a lot of time doing detailed engineering on a change prior for approval.

Part 2 – Managing the Change