RC&E Chill - Industrial Refrigeration and Process Safety / Risk Management

Chill - We Got This!

Page 5 of 13

New Year, “New” SOP Format

December 30, 2019 /

The spirit of Christmas may be behind us, but the spirit of Continuous Improvement never leaves us alone. (for better or worse, lol)

After months of minor changes and revisions off-line, the 2020 SOP templates have been released. Please note: These are IMPROVEMENTS, not compliance or safety-critical changes. As such, there is no need to go back and change your existing SOPs. We would, however, suggest you use these new formats as you implement new SOPs. Of course, it’s possible, you may want to take advantage of some of the features of these new SOP templates, and you’re welcome to convert to them if you have the time.

Changes to ALL SOP Templates:

  1. Moved “Covered Equipment” to “Objective” section which eliminates Document Info section.
  2. Moved “Related Documents” to “Objective” which eliminates Related Documents section.
  3. Removed “SOP Objective” from first section as the objective is repetitive and explained clearly in the Written Plan. (It’s the first text box of the SOP so it’s fairly obvious what the function is!)
  4. Made Safety Warning triangle smaller and made the warning RED. This change (among others) frees up a bit of room for the Safety, Health, Environmental and Equipment Considerations section
  5. Moved the Operator Requirements concerning authorization to the top of the Safety, Health, Environmental and Equipment Considerations section thus eliminating the Operator Requirements section. Also provided a callout to the operator to check their OT1 to ensure they’re qualified to perform the procedure.
  6. Modified the Operating Phase flowchart section layout to take up less space.
  7. Minimized the left-hand column which shows what “Section” you are in to 1” width to take up minimal space. Centered the section text.
  8. Placed Headings between sections. This required splitting up the various Operating Phase / Procedural sections but makes navigation much easier if being used in WORD or PDF format.
  9. Added complementary color to enlarged text “body” sections of Operating Phase / Procedural Sections.
  10. Valve / Component List given a header. Sub-header appropriately colored.

Why did we make those format changes?

  1. Those changes yield a slightly shorter SOP format (average 1 page loss per SOP)
  2. These are collections of various suggestions we’ve received over the past year from end-users.
  3. The resulting SOPs are much more visually appealing, especially on tablets.
  4. The resulting SOPs are much easier to navigate on tablets, which alot of users are implementing for their technicians.

 

Additional changes were made to some other SOP templates:

  1. HPRTSR: Updated the System Charging procedural section based on user feedback.
  2. HPR: Added a Cylinder Charging procedural section for those users that want that option.
  3. LEO: Traditional Permit LEO was simplified and now only has “Existing SOP,” “With Drain Valve,” and “Without Drain Valve” sections. The previous 4 possibilities was confusing to some and this one seems to be easier to understand.

Direct Replacement, Replacement in Kind and Management of Change

December 16, 2019 /

Of all the PSM/RMP requirements, the Management of Change element is the most consistently problematic. Most of the difficulty is in answering two questions:

  • The compliance question: Does the change you considering count as a “change” per the PSM/RMP rule.
  • The safety question: Does the change you are considering have the potential to affect the safety of the process?

Note, it is quite possible that you answer NO to the first question and YES to the second question.

 

The text of the Rule

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.

From a compliance perspective, how broadly you interpret the “…changes to facilities that affect a covered process” portion dictates how many changes will be subject to this element.

Of course, there’s also a little window that allows you to avoid the MOC element if you classify the change as a “replacement in kind.” The rule provides a fairly useless definition of Replacement in Kind:

1910.119(b) …Replacement in kind means a replacement which satisfies the design specification.

The “replacement in kind” exception is routinely abused to avoid MOC. To understand this element better, let’s consider a few scenarios: Replacing a Valve, replacing a Motor, replacing an Ammonia Detector, and replacing a Condenser.

 

Example: Replacing a Valve

In this example, we’re replacing a valve with the same model, size, etc. Is this a change? Some people would call this a Replacement in Kind, but I would not. I would call this a Direct Replacement. It’s not kind of like the valve we’re replacing, it’s exactly like it. Such a change is outside the scope of the MOC element entirely.

What if we were replacing the valve with a different brand or model? Then we don’t know if it is a Replacement in Kind until we ask enough questions to assure ourselves that it satisfies the design specification. Some questions we might ask are:

  • Is it made of the same materials?
  • Does it have the same flow ratings / capacity?
  • Does it have the same mode of operation in manual and automatic?
  • Does it have the same Mechanical Integrity requirements?
  • Does it affect the PHA section that this equipment belongs to?

It’s quite possible that you answer enough questions to assure yourself that the replacement valve satisfies the design specification making it a Replacement in Kind. While this means it is outside of the MOC element for compliance purposes, we’d still recommend you document the rationale you used to determine that it meets these design specifications. You could even take this documentation one step further and declare that in the future all replacements of Brand A Model X valve with Brand B Model Y valve can be considered a Direct Replacement in this application.

 

 

Example: Replacing a Motor

A motor might be considered by some (incorrectly) to be outside of the MOC element because it doesn’t (usually) contain ammonia, but this is short-sighted. Remember, the MOC element is about Changes to…equipment…that affect a covered process. A motor for equipment that is part of your covered process would certainly fall within the scope of the element for consideration.

Ideally, we’re replacing the motor with the exact some one – a Direct Replacement that would place it outside the MOC element. But, if we are replacing it with another motor, we will be looking to prove that it satisfies the design specification so we can consider it a Replacement in Kind. Again, we need to ask questions:

  • Does it have the same electrical requirements (phase, voltage, etc.)
  • Does it have the same frame size?
  • Does it have the same RPM, duty rating, capacity, etc?
  • Does it affect the PHA section that this equipment belongs to?

Just like earlier in our valve example, it’s quite possible that you answer enough questions to assure yourself that the replacement motor satisfies the design specification making it a Replacement in Kind. While this means it is outside of the MOC element for compliance purposes, we’d still recommend you document the rationale you used to determine that it meets these design specifications. You could even take this documentation one step further and declare that in the future all replacements of Brand A Model X motor with Brand B Model Y motor can be considered a Direct Replacement in this application.

 

 

Example: Replacing an Ammonia Detector

Like earlier, with the motor example, a change to an ammonia detector might be considered by some (incorrectly) to be outside of the MOC element because it doesn’t (usually) contain ammonia, but this is short-sighted. Remember, the MOC element is about Changes to…equipment…that affect a covered process. You definitely consider these detectors as safeguards in your PHA, so we need to exercise some caution on this change.

If we’re replacing the detector with the exact same one, then it’s a Direct Replacement. If we’re replacing it with a different detector, we need to assure that it satisfies the design specification so we can consider it a Replacement in Kind. Again, we need to ask questions:

  • Does it have the same electrical requirements?
  • Does it have the same output signal / alarm outputs?
  • Does it have the same sensitivity?
  • Does it have the same Mechanical Integrity requirements? The same calibration equipment, schedule and calibration procedure?
  • Does it affect the PHA section that this equipment belongs to?

In my experience, unless you are dealing with a Direct Replacement, no detector meets the requirements for a Replacement in Kind because they almost all fail the last question on calibration equipment, schedule and procedure. That means such a change would require the implementation of a Management of Change procedure.

Here’s where we can get a little clever. The PSM/RMP rules require that we “establish and implement written procedures to manage changes” but they don’t require that we use the same procedure for every change! If we sit down and think through all we need to do to successfully change from Brand A Model X NH3 detector to Brand B Model Y NH3 detector, we could establish a standard procedure for doing so. That means that in a facility with, say, 45 detectors that you are changing over a period of time, you have a Single MOC (to establish the new procedure) and then simply implement the new NH3 Detector Change SOP 45 times as the changes occur.

 

 

Example: Replacing a Condenser

In this example we’re replacing a brand A evaporative condenser with 500 tons of capacity with a brand B evaporative condenser with 500 tons of capacity. Note: this would work the same with if you were replacing it with a different model of brand A as well. Also, if you were replacing a condenser with an exact duplicate, then theoretically you may be able to get by with a PSSR, but that assumes you don’t need any non-standard operating modes during the change-out.

First question: Is it a change to equipment which satisfies the design specification? Answer: Well, I don’t know because there is a lot that goes into that determination. But every part of a condenser changeout has the potential to affect the safety of your system. Questions you should ask include:

  • Does it have the same electrical requirements (phase, voltage, amp draw, etc.)
  • Is it have the same size and weight?
  • Is it made of the same materials?
  • Does it have the same flow ratings / capacity?
  • Does it have the same mode of operation in manual and automatic?
  • Does it have the same Mechanical Integrity requirements?
  • Does the P&ID need to be updated?
  • Does the SOP need to be updated?
  • Does it affect the PHA section that this equipment belongs to?
  • …and the list goes on.

While it is technically possible that you could ask these (and 100 other) questions concerning a condenser replacement in such detail that you ensure it satisfies the design specification, you are going to want to document all that work. I’ve personally never seen it happen unless it was the same make and model. In our opinion, the best way to document all that work is by following the Management of Change procedure.

 

Closing Thoughts

Management of Change is a difficult element. But by working this element, you can find and address hazards before they are introduced to your process. There’s very little that can be said about it better than this advice from the Petroleum NEP:

OSHA’s MOC requirement is prospective.

The standard requires that an MOC procedure be completed, regardless of whether any safety and health impacts will actually be realized by the change. The intent is, in part, to have the employer analyze any potential safety and health impacts of a change prior to its implementation. Even if the employer rightly concludes there would be no safety and health impacts related to a change, 1910.119(l)(1) still requires the employer to conduct the MOC procedure.

PSM is a Thief!

October 30, 2019 /

The view that PSM is a time-sink.

A common push-back from facilities that are covered under the OSHA PSM and EPA RMP regulations is the sheer amount of resources these programs require to successfully design, implement, and maintain.

One phrase, seared into my memory, is from a frustrated and over-burdened maintenance manager: “PSM is a thief!”

He was referring to the fact that he had to task high-performing, highly trained and highly compensated personnel to perform Process Safety tasks. Time spent on Process Safety is obviously time that isn’t spent elsewhere.

My counterpoint at the time was “Safety isn’t earned – it is rented. And the rent is due every damned day”

After an experience I had last week, I think there’s a better way to respond. I’d like to share my new response with you, but first let’s talk about the experience that made me see a new way of approaching this issue.

 

The experience

During the recent RETA conference the guest speaker was Jóse Matta. Jóse suffered ammonia burns over 40+ percent of his body when a condenser failed in an overpressure event. The event involved a portable ammonia refrigeration system. Before transport the system is drained of ammonia. In this incident, the driver placed a cap on the relief valve outlet due to DOT concerns. However, once the unit arrived onsite, the capped relief valve wasn’t noticed. Eventually this led to an overpressure event once the unit was charged and started.

Jose Matta barely survived his exposure. He nearly died in the hospital. His wife was brought into the burn unit to say her final goodbyes to her husband – the father of their children. When he was lucky enough to survive, he had to endure multiple surgeries. He no longer has a sense of smell and can barely taste food. He no longer has the ability to sweat and has to constantly monitor his condition when it’s hot out to avoid heat-stress or heat-stroke.

 

What does Jose’s experience have to do with “PSM as a thief?”

Post-incident, several failures of the PSM program were noted:

  • Pre-Startup Safety Review failed to identify the capped relief.
  • SOPs and Training on startup either weren’t adequate to control the hazards, or weren’t followed.
  • Setup time and tight scheduling, location of safety showers, weren’t adequately addressed in the PHA.
  • The MI program didn’t ensure that the high-discharge-pressure interlock worked.
  • The technician and contractors at the site weren’t familiar enough to know there was a safety shower located in a nearby building.
  • The EAP didn’t provide adequate information to the facility or responders, leading to them delaying effective treatment.
  • There was no command system in place. Nobody called 911. Nobody took charge. Nobody met the responders when they arrived to explain what was going on.

If the Process Safety items above were properly in place, the incident either wouldn’t have happened, or the outcome would have been significantly better for Jóse.

You see, when I pushed back from the “PSM is a Thief” argument before, I was wrong. I should have agreed with that statement.

 

PSM *is* a thief. Yes, it takes resources, but it can also take a LOT more from you!

PSM can steal from you: the opportunity to nearly die in a chemical release.

PSM can steal from your family: the opportunity for tearful goodbyes.

PSM can steal from you: years of surgeries, painful rehabilitation, and diminished health.

 

Yeah, PSM is a thief. I’m plenty happy to have these experiences stolen from me and the people I work with.

Without Process Safety, people are taking risks without knowing they are taking them. NOBODY should have to do that.

If you want your Process Safety program to steal these experiences from your facility, your coworkers, your neighbors, and YOU, we can help!

Dealing with non-standard (non-routine) work in your Process Safety program

October 17, 2019 /

Occasionally we come across an issue we’ve customarily addressed, but never documented. Put another way: We realize we have a policy – even if an informal one – on how to deal with certain situations, but we’ve never turned that policy into a formal, written one.

It’s incredibly common to have these informal policies in smaller departments, or when a task is rare. You can usually identify them after-the-fact when you are told “That’s just the way we do things here. Everybody knows that.”

When we find these items in our Covered Processes, we should endeavor to document them. Today I’d like to talk about a big one: What do we do when the existing written procedures don’t match with the conditions or situations we are facing in our work. What written guidance are you providing to your Process Operators and Technicians on how to deal with this situation?

Every functioning Operations / Maintenance department has a policy – even if an informal, undocumented one – on how they deal with this issue.  

For years I’ve relied on the text in the SOP Written Plan concerning Temporary Operations:

The ammonia system is not operated in any temporary modes without a written SOP. If a component requires maintenance or replacement, that portion of the system is isolated and removed from service through a written SOP. Other Temporary Operations are handled through the MOC element which will ensure supervisory oversight. Temporary Operation SOPs are often via a written modification of an existing SOP in the form of an addendum.

This worked well, but it was a little bit obscure and (understandably) only thought to apply to SOPs themselves. That needed to change. What we’ve done to our system today, is formalized and documented guidance on how to deal with these non-standard / non-routine situations.

A new policy was placed in the RMP Management System Written Plan…

To ensure integration of this policy, the following text was added to the Operating Procedures (Implementation Policy: Using an SOP – Performing a Procedure, and Implementation Policy: Operating Phases, Temporary Operations) and Mechanical Integrity (Implementation Policy: Mechanical Integrity Procedures or MIPs) element Written Plans: “The Implementation Policy: Non-Standard Work. Addressing Conditions / Situations outside of existing Procedures found in the RMP Written Plan should be used when site/equipment/system Conditions or Situations are found to be different than those anticipated in the exiting written procedures.”

Are you handling non-standard / non-routine work well in your Process Safety program? If you are, and have a better idea, we’re always open to improvements. If you aren’t handling it well, perhaps you can implement the example above? 

For Inside-Baseball type people: This chart was inspired by the API RECOMMENDED PRACTICE 2201 Safe Hot Tapping Practices in the Petroleum and Petrochemical Industries, Chapter 4, Section 4.3.1, Figure 3—Example Decision Process for Authorizing Hot Tapping. Other than genericizing that flowchart to cover all types of work, I also made two large changes:

  • Routed the post “change conditions” step back to the start so we re-evaluate the existing procedure considering changed conditions/situations rather than short-circuiting back to the Management step.
  • Rewrote the flow/wording so that Condition Changes are preferred over mere procedural changes. The thinking was that we should prefer more engineering-type changes over administrative ones, where possible.

 

RAGAGEP Deficiencies and building a defensible case for an alternative solution

October 1, 2019 /

This issue: During a PHA, the facility is using an IIAR 2-2014a checklist and finds that the installation does not meet the requirements of section 6.14.3.3.

6.14.3.3 *Machinery room exhaust shall be to the outdoors not less than 20 ft (6 m) from a property line or openings into buildings.

The distance from the machinery room emergency exhaust outlets on the roof to a rooftop door leading into the building is approximately 8 feet. This is a 1910.119(j)(5) deficiency and a 1910.119(d)(3)(iii) RAGAGEP violation. They have a recommendation to address the issue.

Let’s think about the implications of this issue.

 

The Analysis: If there was an ammonia leak in the machinery room that activated the emergency ventilation, then the fans would exhaust on the roof very close to this door. In PHA terms, this could be thought of as a “siting” issue.

This situation is pretty rare: only technicians are allowed on the roof, and they are only up there for routine inspections and maintenance. Still, there are two ways the technician could be exposed to this hazard. If they used the door to:

  1. Access the building’s internal stairway from the roof.
  2. Access the roof from the building’s internal stairway.

For situation #1, a release would be easily observed / heard while on the roof in the area of the ventilation fans. There are also other entrances back into the building, including external stairs to the ground level. The team decided this situation was acceptable without any changes.

For situation #2, it would be possible (although not likely due to the noise of the fans) that someone could use the door to access the roof without knowing that they could be exposed to a release on the other side of the door. The team decided this was an unlikely, but possible issue. That is – it’s an unlikely turn of events that a release in the machinery room would occur at the same time as someone would be using the door – but it was possible so it should be addressed.

Obviously, the cleanest solution would be to move either the door or the fans, but that’s not an easy thing to do! Also, it would be a very expensive fix for an issue with such a low probability of occurrence.

The team brainstormed a bit and came up with an alternative plan to address the issue.

 

The chosen Solution: First, there are only two ways the fans could be exhausting a large amount of NH3 vapor. Either they would me manually operated due to maintenance / leaks or they would be automatically operated due to the IIAR 2-2014a 6.14.7.2.1 required NH3 detection interlock. Either way, a RUN signal is sent to the fan controls and the team decided to install a visual alarm on both sides of the door and use this RUN signal to activate it. Coupled with proper signage and training, the team believes the alarm would provide adequate warning to anyone approaching the door that the emergency ventilation system was running and that the door should not be used.

The team believes this is a defensible solution to non-compliance with IIAR 2-2014a 6.14.3.3. I tend to agree with them – it’s defensible if imperfect.

Perhaps another, actually compliant solution, would be to install ductwork on top of the emergency exhaust fans to raise the exhaust point so the distance from them to the door would meet the 20-foot requirement. Of course, such a change would require a new ventilation calculation to ensure the additional restriction caused by the duct work didn’t pose a problem. This ducting solution would likely be a bit expensive and that could mean that it would take some time to implement. If this duct solution was chosen,  the earlier “alarm” idea would be an excellent interim measure until approval and construction of the ducting project occured.

Note: This 20’ requirement appears to show up first in IIAR 2-2008a effective August 2010. Previously the requirement was a vaguer “13.2.3.11 The discharge of air shall be to the atmosphere in such a manner as to not cause inconvenience or danger.”

Hot Work – NFPA 51B–2019 and Magic Rooms

September 26, 2019 /

RAGAGEP is always changing and we have to ensure that our safety programs evolve to match the new / changed requirements. Tuesday I took a dive into NFPA 51B 2019, the standard for “Fire Prevention during Welding, Cutting, and Other Hot Work.” After reading through it, some changes were made to my base program. Here’s the section from my running “Change Log”

092419 – Updated both versions Hot Work Written Plans to deal with NFPA51B-2019.

  • Changed NFPA references to match new section numbers
  • Changed fire watch to 60-minute minimum per NFPA.
  • Updated master definitions file (in \01-RMP\ ) to include updated definition of Fire Watch and new definitions for Fire Protection System and Fire Monitoring.

To Implement:

  • Change out \01 – EPA RMP\Definitions – Glossary of Terms and Acronyms with 092419 version by using the appropriate MOC procedure.
  • Replace \09 – Hot Work\09 – Hot Work Permit Element Written Plan with 092419 version by using the appropriate MOC procedure.
  • Train all personnel involved in Hot Work about new 60-minute fire watch requirement. Document training per the written plan.

 

This is a fairly simple change. You may have noticed that there is a new section in the “Change Log” for each entry – a “To Implement” section that tells you how to modify your program if it was written based on the baseline templates. I’ve gone back through the last month’s changes and added this information. Time willing, I might do the same for the previous 100+ entries!

While we are on the subject of Hot Work though, I want to bring up another common issue: “Designated Areas.” This is a particularly “Hot” topic right now, because a recent large industrial fire was caused by Hot Work and some people are saying it was an oil fire caused by Hot Work done in a “shop.”

Designated Areas: Many plants have “Designated Areas” such as maintenance or welding shops where Hot Work is conducted without the use of a permit. It should be noted that nothing in the PSM/RMP or OSHA General Industry rules (as interpreted through 1910.119(k)) appear to support this. For this reason, we’ve always called these areas “Magic Rooms” because people seem to think that these rooms are exempt from OSHA rules. The custom actually comes from NFPA 51B:

In the 2019 version, it is section 5.3.2.1 which allows for areas to be classified as Designated Hot Work areas. These areas would allow Hot Work without the use of the written permit provided certain requirements are met:

  • The specific area designed or approved for Hot Work meets the requirements of 5.5.1*
  • The area is reviewed at least annually by the Permit Authorizing Individual
  • Signs are posted designating Hot Work Areas
  • Prior to the start of the Hot Work, the operator verifies the following:
    • The location is verified as fire resistant.
    • The requirements of 5.4.2(3) are met so that the area is essentially free of combustible and flammable contents.
    • Fire extinguishers are in working condition and readily available.
    • Ventilation is working properly.
    • Hot Work equipment is in working order.

* Section 5.5.1 is the list of requirements that have to be met before issuing a Hot Work Permit. Essentially, you are making sure that the Designated Area meets the requirements for issuing a Hot Work Permit without actually issuing one.

The acceptability of this custom is in question due to a statement made by OSHA in their PSM Preamble:

“…this proposed provision would not require a permit for Hot Work operations in a welding shop unless the welding shop was located in a process area covered by the standard. OSHA believes that such a location would not exist.” (OSHA, PSM Preamble, 1992)

OSHA was clearly thinking of Petroleum and Chemical plants in that quote, where such situations are usually not found. As of 2019, we are not aware of any Ammonia Refrigeration PSM-covered facility receiving a Hot Work citation for Designated Areas if they follow the requirements of NFPA 51B Section 5.3.2.1. Still, it would be far more defensible if you issued Hot Work permits for all Hot Work, even that work conducted in maintenance and welding shops.

 

Here’s a look at the Hot Work element Written Plan section dealing with Designated Hot Work Areas:

Note: Previous discussion on Hot Work at this link. You can read the 2019 version of NFPA-51B in its entirety at NFPA.org

 

Questions from the field: Who is responsible for the PSM/RMP duties?

September 18, 2019 /

From a legalistic perspective, we’ll first turn to the law. In this case, the EPA’s RMP rule…

68.15(a) The owner or operator of a stationary source with processes subject to Program 2 or Program 3 shall develop a management system to oversee the implementation of the risk management program elements.

68.15(b) The owner or operator shall assign a qualified person or position that has the overall responsibility for the development, implementation, and integration of the risk management program elements.

68.15(c) When responsibility for implementing individual requirements of this part is assigned to persons other than the person identified under paragraph (b) of this section, the names or positions of these people shall be documented and the lines of authority defined through an organization chart or similar document.

The short, legalistic answer is that the owner/operator is responsible. They must pick a qualified person who has overall responsibility for the program.

If the owner then chooses to break up the various requirements of the program to people other than that qualified person, they have to document all those people. In my programs, I call these people a “Responsible Person.”

 

Ok, but how does this actually work. Let’s imagine a small facility that is required to have a PSM/RMP program. They pick their Safety Manager, Sofía as their Process Safety coordinator, so she is now the person responsible under §68.15(b).

But, Sofía, while very knowledgeable in Safety and Environmental issues, is not as familiar with refrigeration or engineering. It’s unlikely she’ll be in the best position to manage most of the program elements on a day-to-day basis.  To address this issue, the facility decides to assign certain skilled people the responsibility for various program elements. They assign the Operating Procedure, Operator Training and Maintenance elements to Robert, their Maintenance Manager. They also decide to assign the Process Safety Information, Management of Change and Pre-Startup Safety Review elements to Jaylen, their Plant Engineer.  Because he usually manages them anyway, they assign Benny, the Lead Operator, the Contractor element. Of course, all these people are going to rely on the knowledge and experience of each other, the Facility Manager John, and the other operators, Tessa, Faraz, and Tiah.

This might be getting a little confusing at this point, which is why §68.15(c) wants us to document these assignments. For example:

Program Element Responsible Person
Overall PSM / RMP Management System PSM Coordinator
Risk Management Plan (RMP) PSM Coordinator
Process Safety Information Plant Engineer
Employee Participation PSM Coordinator
Process Hazard Analysis PSM Coordinator
Operating Procedures Maintenance Manager
Operator Training Maintenance Manager
Contractor Qualification and Safety Lead Operator
Pre-Startup Safety Review Plant Engineer
Hot Work Permit PSM Coordinator
Incident Investigation PSM Coordinator
Mechanical Integrity Maintenance Manager
Management of Change (MOC) Plant Engineer
Emergency Response Plan PSM Coordinator
Compliance Audits PSM Coordinator
Trade Secrets PSM Coordinator

How a facility arranges the responsibilities is entirely up to them as long as they can make the case that the person assigned as a “Responsible Person” is qualified to handle the work being assigned to them.

On a practical level, your Management System should also:

  • Show what person is responsible for each PSM/RMP element / requirement
  • Ensure that only one person is responsible for each requirement
  • Make it clear that a Responsible Person can’t authorize their own work requests, such as Hot Work, MOC, PSSR, etc.
  • Be easily understood by everyone involved

Please note, that just because someone is responsible for an element, doesn’t necessarily mean they are actually doing the work. They are just responsible for ensuring the work is done. A good example outside of PSM is the facility manager of a chicken plant. That facility manager is responsible for ensuring that food safety regulations are met so the chicken is cooled in an appropriate time-frame. It is extremely unlikely that the plant manager actually handles the chicken, the cooling equipment, etc. They simply provide the resources and oversight to ensure the work is done properly.

A good PSM example might be Operating Procedures. In our case, we’ve assigned them to the Maintenance Manager. It is likely that the actual initial creation and review of the operating procedures is done entirely by the operators. Based on the results of that review, the Responsible Person would ensure that appropriate revisions are made and then certify the procedures.

Feel free to contact us If you want templates of a PSM/RMP management system.

Compliance Auditing and the Karenina Principle

August 2, 2019 /

Over the years I’ve audited well over one hundred Ammonia Refrigeration Process Safety (PSM / RMP) programs and one of the things that I always try and remember during the audit is something called the “Anna Karenina” principle. The first line in that Leo Tolstoy novel is:

“All happy families are alike; each unhappy family is unhappy in its own way.”

 

Put another way: Success requires certain key factors are addressed. Meeting those requirements means that those successful systems will be similar to other successful systems. For Process Safety programs, there are many key factors to success, but I think they all boil down to three main categories:

  • Does the facility have a written Process Safety Program that (on paper) meets the safety & compliance requirements of the law, the process, and the people, in a manner that meets the business needs of the company? If so;
  • Is the written Process Safety Program implemented as written? If so;
  • In the actual day-to-day process, does the written Process Safety Program as implemented address the safety & compliance requirements of the law, the process, and the people, in a manner that meets the business needs of the company adequately?

I often call this the “Three Levels of Compliance.” Shown in a flowchart:

While there are nearly infinite ways a Process Safety program can fail, but ALL successful programs will pass these three levels of compliance checks. Understanding this concept will help you be a better auditor, but it can also help you be a better implementer!

 

In Auditing, how does this work in practice?

Let’s look at an example of an identified deficiency of rusted pipe found during the walkthrough portion of an audit. Note, we’ve kind of started at the 3rd level of compliance here because we’ve found a problem in the field and therefore know that the plan as implemented isn’t adequate!

First-pass question concerning written plan could include:

    • Are there written instructions on their inspection frequency and acceptable conditions?
    • Is there a written plan on training to perform these inspections?
    • Does the written Mechanical Integrity Plan address these specific pipes?

The answers to these questions will help you define a finding / recommendation to improve the program.

Second-pass questions concerning implementation could include:

    • Is the written Mechanical Integrity Plan that addresses these pipes being conducted when it is scheduled to be?
    • Are the written instructions being followed?
    • Was the inspector trained in accordance with the written plan?

Again, if the answers to these questions may prompt a finding / recommendation to improve the program. If you have a written MI plan and you are implementing it, but you still have rusting pipes; then you need to fix either the plan or your implementation of it!

 

How can this concept help me be a better implementer?

Your Process Safety Program is, by its very nature, artificially bringing order to chaos. Because of Entropy, we know that all systems and processes will eventually decline into disorder and fail. This decay happens with no effort on your part but, with effort, it can be thwarted.

Ultimately. I believe the only way to continuously, sustainably maintain your Process Safety Program is by forcing a feedback loop. A feedback loop is where you ensure that the output of a system is routed back to the input of the system. In our earlier worked example, we need to ensure that the output (physical condition, daily practices, etc.) of the system is routed back to the input (written plan and implementation of it) so we can know how well the system is performing and make changes as needed.

When it comes to the mechanical world, there is no better feedback loop that actual inspections and tests. If it is properly designed, your Mechanical Integrity program should be providing this information. Your team needs to understand that (no matter how small) every single deficiency you find, or breakdown that you have, is a sign that your plan can be improved.

When it comes to the operation of the system (policies, procedures, etc.) your PSM team is supposed to be providing this feedback. I say “supposed to be” because more and more I see that this important feedback loop is not being properly utilized. For more information on what the purpose of a PSM team is and what it should do see this earlier article: What is the purpose of a PSM Team?

What is the Purpose of a PSM Team?

July 30, 2019 /

The implementation of the PSM/RMP Program is a team-based effort. In my opinion, no single part of a Process Safety Program is more important than your Process Safety Team. Put another way: If you don’t have a strong Process Safety Team you won’t have a strong Process Safety Program.

 

Who should be on the Team?

At a minimum:

  • Each Responsible Person listed in the “Management System” is a member of the PSM team. Responsible Person’s are people that have responsibility for implementing individual elements of the Process Safety Program.
  • If not already included as a Responsible Person, all Process Operators are also included as PSM team members.

The team can also benefit from additional diversity such as senior members of management outside of Process Safety. Examples might include the Plant Manager or Director of Warehousing, Production Supervisors /Managers, Health, Safety & Environmental staff, etc.

 

What should the team do?

While a successful team serves many functions, it is there for two essential purposes:

  • To educate and inform
  • To provide oversight

 

Process Safety Team as an Educator

Your covered process and the safety programs that cover it are large and complex. So it the overall business that they are a part of. Our first priority in the meeting is to inform each other of what is happening in the parts of the program we deal with on a daily basis – or we are responsible for. This is often referred to as “getting everyone on the same page.”

 

Process Safety Team’s Oversight Role

The most often failed function of a Process Safety Team is to provide oversight. The Responsible Person for an element has to make day-to-day decisions to keep the process (and the business) running and we should ensure that they defend these decisions to the Process Safety Team so that the team can either validate or correct them.

For example:If the MOC Responsible Person decided that a specific change was not required to go through the MOC process, they should make that argument to the Process Safety Team which should either validate that choice or – as a group – convince the Responsible Person that their decision was in error so they can take corrective action.

Another example: The Responsible Person and two other staff members have completed an Incident Investigation on a small process leak that recently occurred. The Process Safety Team should either validate that completed Investigation or – as a group – convince the Responsible Person to investigate additional avenues, or provide addition recommendations.

This simple concept: Defend your decisions to a team of your peers so they can validate them or correct your thinking is the beating heart of any Process Safety Program. If you do it well, you provide a feedback loop, and the entire team will get better at their jobs. Whether it’s an Incident Investigation, a Management of Change, Contractor evaluations, etc., Validating your decisions with your Process Safety Team will improve the performance of the program more than nearly any other thing you can do.

 

Bonus Content: What should we discuss at our PSM meetings?

I am often dumbstruck when this question is asked of me, because I NEVER run out of things to talk about. (You can all stop laughing now)

While PSM Team Meetings should be structured to allow diverse topics and input, certain topics should be discussed at any general PSM Team Meeting:

  • Any open recommendations in the program to review status and ensure recommendations are progressing towards resolution.
  • Any upcoming, ongoing, or recently completed MOCs, PSSRs, Incident Investigations, etc. to review status and/or adequacy of documentation.
  • Any upcoming, ongoing, or recently completed work that has, or may have, safety ramifications for the covered process(es).
  • Team Validation of any decisions / work product produced by Responsible Persons

 

Note: Special thanks to end-users VD & CG who prompted me to include this information (and more) directly into my PSM Element Written Plans. We ALL improve with feedback!

 

« Older posts Newer posts »

Contact Us

© 2024 RC&E Chill – Industrial Refrigeration and Process Safety / Risk Management

Theme by Anders Noren — Up ↑