This week’s Pipeliners Podcast episode features Ross Adams of EnerSys Corporation interviewing Pipeliners Podcast host Russel Treat about how to overcome challenges in alarm management for the pipeline control room.
In this episode, you will learn about the influence of the PHMSA CRM Rule on alarm management, the value of optimizing alarm rationalization to help controllers achieve situational awareness, the importance of linking together PSM in alarm management, and more topics.
Alarm Management Challenges: Show Notes, Links, and Insider Terms
- Ross Adams is the Regulatory and Software lead for EnerSys Corporation. Connect with Ross on LinkedIn.
- Listen to Ross’ previous appearances on the Pipeliners Podcast.
- EnerSys Corporation is a recent sponsor of the Pipeliners Podcast. Find out more about how EnerSys supports pipeline operations compliance, audit readiness, and control room management through the POEMS software suite.
- PHMSA (Pipeline and Hazardous Materials Safety Administration) is responsible for providing pipeline safety oversight through regulatory rulemaking, NTSB recommendations, and other important functions to protect people and the environment through the safe transportation of energy and other hazardous materials.
- The CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
- The Bellingham Pipeline Incident (Olympic Pipeline explosion) occurred on June 10, 1999, when a gas pipeline ruptured near Whatcom Creek in Bellingham, Wash., causing deaths and injuries. Three deaths included 18-year-old Liam Wood and 10-year-olds Stephen Tsiorvas and Wade King.
- Alarm management is the process of managing the alarming system in a pipeline operation by documenting the alarm rationalization process, assisting controller alarm response, and generating alarm reports that comply with the CRM Rule for control room management.
- Alarm rationalization is a component of the Alarm Management process of analyzing configured alarms to determine causes and consequences so that alarm priorities can be determined to adhere to API 1167. Additionally, this information is documented and made available to the controller to improve responses to uncommon alarm conditions.
- An alarm management program is a method to manage the alarm rationalization process in a pipeline control room.
- Alarm rationalization is a component of the Alarm Management process of analyzing configured alarms to determine causes and consequences so that alarm priorities can be determined to adhere to API 1167. Additionally, this information is documented and made available to the controller to improve responses to uncommon alarm conditions.
- SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at a remote location. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.
- PLCs (Programmable Logic Controllers) are programmable devices placed in the field that take action when certain conditions are met in a pipeline program.
- P&ID (Piping & Instrumentation Diagrams) are detailed diagrams that capture how the piping and process equipment in the field go together with the instrumentation and control devices in a control system.
- HMI (Human Machine Interface) is the user interface that connects an operator to the controller in pipeline operations. High-performance HMI is the next level of taking available data and presenting it as information that is helpful to the controller to understand the present and future activity in the pipeline.
- Doug Rothenberg is the President and Principal Consultant of D-RoTH, Inc., a technology consulting company providing innovative technology and services for industry. Doug’s specialty is control alarm management training and consulting for the industrial process industries.
- Process Safety Management (PSM) refers to a set of interrelated approaches to managing hazards associated with the process industries and is intended to reduce the frequency and severity of incidents resulting from releases of chemicals and other energy sources.
- Process Hazard Analysis (PHA) analyzes the potential causes and consequences of an incident involving natural gas, hazardous liquids, or other product in a pipeline system.
Alarm Management Challenges: Full Episode Transcript
Russel Treat: Welcome to the Pipeliners Podcast, episode 163, sponsored by the American Petroleum Institute, driving safety, environmental protection, and sustainability across the natural gas and oil industry through world-class standards and safety programs. Since its formation as a standards-setting organization in 1919, API has developed more than 700 standards to enhance industry operations worldwide. Find out more about API at api.org.
Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now your host, Russel Treat.
Russel: Thanks for listening to the Pipeliners Podcast. We appreciate you taking the time. To show the appreciation, we give away a customized YETI tumbler to one listener each episode. This week, our winner is Tim Owens with the Metropolitan Utilities District of Omaha. Congratulations, Tim. Your YETI is on its way. To learn how you can win this signature prize, stick around till the end of the episode.
This week, Ross Adams returns but as the interviewer. I get to be the guest. Stick around while we flip the script. Ross, welcome back to the Pipeliners Podcast.
Ross Adams: Thanks so much. It’s a pleasure to talk twice in just a short period. I’m excited to be here. I heard we’re going to do things a little different this time. Is that right?
Russel: Oh yeah. Absolutely. We’re going to flip the script, buddy. You’re going to be the interviewer. I’m going to be the interviewee. I’ve been doing a whole bunch of podcasts where I was very steep on the learning curve. Now I want to do one where I’m the expert, just so that going into the end of the year I feel good about myself.
Ross: That’s a great way to end the year. I tell you, your listeners are in for a treat. I know in working with you, I’ve learned a whole bunch. With the topic that we have today, diving into that, there will be plenty for them to digest. They’ll be better for it.
Russel: We’re here to talk about alarm management. I’m just going to hand it over to you and let you take it away.
Ross: This is a really important topic. In my experience going through and supporting control rooms, just on an ongoing basis, and facilitating a lot of the tasks that they have to do to comply with the PHMSA rule, but also helping them to prepare for audits, I’ve noticed that the area of alarm management can be difficult.
When done well, there’s some things that control rooms can pursue to handle alarm management well. I really would like to dive into all that. Hopefully, folks will leave here today with an understanding of really what alarm management is and the opportunities and challenges associated with it and maybe how they can better improve their alarm management program.
To begin, maybe the best thing to ask is, how’d you start to learn about alarm management yourself?
Russel: That’s a great question. I grew up doing measurement. Measurement led to doing some telecoms. That led to doing some HMIs. That led to doing SCADA. Back in 2007, we were looking at our future planning and watching the control room management move through the process. We knew it was coming.
We were looking at these things, situational awareness and high-performance HMI and alarm management and all these other requirements. It became pretty clear to me pretty quickly that I didn’t know any of that stuff. We went out and looked for some experts.
A gentleman by the name of Doug Rothenberg was referred to me as the guy to go to. Doug literally wrote the book on alarm management. In fact, he’s been on the podcast before. We’re going to have him on again here in the next few weeks. He’s just a really smart guy.
We brought him in as a consultant. The whole goal of that exercise was to learn from him. Doug learned alarm management and had written all of his stuff about alarm management in the process industry, so nuclear power, petrochemical, refining, that sort of thing.
Pipelining is a little different. Once we understood Doug’s approach, we began to take and adopt it as we worked with customers. I would say we’ve learned a lot in the 10-plus years since we first started doing this with Doug Rothenberg.
Ross: Maybe as a philosophy at a high level, what are some of the things that you learned from Doug? What’s important about alarm management? Why do pipelines even need alarm management?
Russel: That’s a great question, Ross. I think it’s a two-part answer. First, I’m going to talk a little bit about why do we have it versus why do we need it. The reason we have it is because of the Control Room Management Rule.
The Control Room Management Rule, while it came out of a number of incidents, it largely came out of Bellingham. Bellingham was a landmark moment in pipeline operations and pipeline regulatory requirements because a gasoline line had a leak. It got into a waterway, a creek, and a number of people or kids…It’s a pretty horrific incident.
One of the things that was operating there is they were getting alarms but they were getting alarms at a time when work was being done on the pipeline. They were consequently ignoring the alarms. Coming out of Bellingham, they began to place these alarm management requirements.
Alarm management’s been around for a long time in other industries, but it started in pipelining with the control room management rule. The reason we need it, getting beyond the regulatory requirement, but answering the question, why is it important? What the science will show is two things.
One, that if somebody gets too many alarms in too short a period of time, they just start ignoring everything. That’s bad. The other thing that it shows is that there’s a certain amount of time required to work an alarm. To the extent that you can predesign the alarm response, you can become more effective.
Really, alarm management was about making the systems provide information that would make the controllers more effective and making the systems throttle the information to just what the controllers need in order to be able to prioritize and respond to alarms.
Ross: That’s all incredibly interesting. If anything’s true, it’s that as these control rooms began to mature, and as these rules started coming out, one of the focuses was on consistency in HMI.
The focus, all the NTSB Pipeline Acts or reports and whatnot that were considered when writing the CRM Rule had a lot to do with not only HMI, but alarm response, as well, and making sure the controllers thoroughly understood why those alarms were activating and what the required response was supposed to be.
Russel: The rule’s been around for about 10 years now. A lot of control rooms started implementing things in advance of the rule. We’re actually getting to a point where there’s a whole generation of pipeline controllers that may not have any experience running a pipeline without alarm management.
One of the things that was going on, it was very common for a console to have one or two hundred alarms every hour. If you think about that, that’s more than one a minute. There’s no way that you can actually effectively respond to that.
Nowadays, a well-run control room is probably seeing less than six alarms in an hour, on average. A pretty significant change.
Ross: Yeah, it’s a huge difference, in terms of the controller experience and their ability to really process effectively any kind of corrective actions that they’ve got to take.
I know you and I’ve talked about just how important understanding and recognizing alarms and abnormal operating conditions has been. That was a great podcast, I thought, that you were able to do. I know you’ve got another one on Bellingham that we ought to link up in the show notes in case people are interested.
I think you’re right. That incident was incredibly moving and certainly was a pivotal moment for us as we developed both in the rule and in the control rooms and the ways that we operate.
With that being said, I know that, like I said, from my experience with working with all kinds of different control rooms, different sizes, different staff levels, for all of them, with some exception, alarm management seems to be a challenge.
I guess, in your experience, what do you see as being difficult about alarm management? Is it staffing? How much implementation’s required? What are you thinking?
Russel: Ross, it’s a number of things. I think one of the things about alarm management versus other things that are required in the Control Room Management Rule is the control room can’t do alarm management by itself.
Doing alarm management effectively is going to impact the SCADA engineers. It’s going to impact the automation people. It’s going to impact the safety people. In doing a good job of it, you’ve got to actually get outside of the control room to do it. That’s one of the challenges. That makes resources an issue, just in general.
The other thing is rationalization. Rationalization is the process of taking each alarm and defining what happens if it’s not effectively managed. How long do you have to respond? Determining what severity level should be associated with this alarm or the potential adverse outcome. Determining what are the potential root causes of the alarm and then determining what the responsive action should be.
Doing all of that in advance. Working through that process is challenging, to say the least. Anybody who’s sat through a process hazard analysis in a PSM process understands just how that can be. Everybody knows that’s important work, but it can be tedious.
Another challenge, often, is getting everybody on the same page about the definition of an alarm. We define an alarm as it requires response from a controller or something bad’s going to happen. Everything else in the SCADA system that SCADA calls an alarm when you configure it but doesn’t require a response, we call that a notification.
It’s getting clear about what alarms actually are from a controller standpoint. Alarm’s one of those words that we use in lots of departments to mean a lot of things. It means something very specific in this context. Just getting on the same page about all that’s a challenge.
Likewise, your philosophy, if you will, about am I going to manage alarms in the SCADA system. Am I going to manage alarms in the field automation? Do I need to manage it in both places?
Ross: What’s the difference?
Russel: Typically in a PLC, I’m going to establish a set of tags, so the process value like the pressure, the live pressure. I’ll have an alarm limit, typically called a high. I might have a low alarm with a low pressure and a high alarm with a high pressure. Then, I’ll have a shutdown limit, where the automation will shut the process down if I get to that pressure, either high or low. Set of five tags in the PLC.
In the SCADA system, I’m probably also going to have a high and a high-high alarm that I can set in the SCADA system. It raises the question, do I manage those alarms in the SCADA system by the SCADA group in the back office, or do I manage those alarms in the field with the automation group? Do I do both those things and try to coordinate it?
I have seen lots of answers to that question. I don’t think any that I have seen in practice are ideal. It’s just challenging.
Ross: I get the reason to have both would be that if you have alarms in SCADA, you’re notifying your controller that they need to take action in advance of the PLC taking action for them. Is that accurate, or am I way off?
Russel: Maybe. I think, probably a little bit more accurate would be to get to the difference between process safety management and alarm management. Actually, this is another one of the challenges.
We, as an industry, have bought into process safety management. For the facilities that are covered by OSHA, PSM is a regulatory requirement.
PSM requires a review where you get, again, kind of the same group of people you get together to do alarm management, but your focus there is that for any upset, the facility will put itself automatically into a safe state. That can be done through automation. It can be done through mechanical safeties, but you’re looking at all of that.
You’re asking, what happens if somebody inadvertently closes this valve? What happens? If there’s an upset, how would it manifest? What do I do to catch it? What do I do to manage or mitigate it so it doesn’t cause a failure? It’s just an upset.
That’s all about what I would call physical safety, making sure when there’s an upset, the system is going to make itself safe. That looks like mechanical release or shutting the process down automatically.
The challenge is, in alarm management what you’re really trying to do is get an alarm before you have the upset and then have automation in place to head the upset off. Alarm management PSM uses a lot of the same resources.
They use P&ID drawings, and cause/effect diagrams, and the same kinds of people, but the questions they’re trying to answer are different. The PSM question is, how do I make sure if I have an upset and nobody’s there that the system automatically puts itself in a safe condition?
The alarm management question is, how do I identify an upset in advance and make sure I have the ability to make changes to the process so I don’t hit the shutdown? Those two things, while they’re not…They’re different sides of the same coin, but if I go into a system that’s had a good job of PSM and I try to apply alarm management, it can get really complicated.
Ross: It makes sense. If I’m a control room representative, what’s my involvement in either the PSM, potentially, or maybe even a PHA, as it relates to the alarm management process?
Russel: I think that’s a little bit all over the map. I’ll answer that question the way I think it ought to work. I think, ideally…In fact, I did a podcast with a guy by the name of Stephen Swanson about combining the PHA and the alarm management into a single process.
If listeners want to take a deeper dive into that question, Stephen did a great job on that podcast talking about that. He’s a PHA expert. We had done a project together. The control room needs to be involved in both.
If I do a PHA without a control room involvement, then I’m going to look at it differently than if the control room’s in there asking the question, how do I make sure I can catch that and correct it before we have a shutdown?
That’s the key role that you want the control room to be playing in both of those processes. How do I catch it? How do I do something in the control system, from the control center, to head off the shutdown?
Ross: Makes sense. All of this feeds into the rationalization process. That’s not an easy task to do. It typically takes quite a bit of time or different personnel that may have some education. What about resources and resource management may make this alarm management a challenge?
Russel: You talk about the challenge. I actually think that if you can take and combine your PHAs with your alarm management you’re going to have to…The PHAs are a regulatory requirement for OSHA facilities. By combining them, you actually have an opportunity for some savings from a resource perspective.
You’re going to take the PHA and make it take a little bit longer, but if you try and do them separate, you’re almost doubling the level of effort if you’re doing a proper job.
What people tend to do, because the resource is challenging — getting all these people in a room — what they tend to do is they tend to want to make simplifying assumptions and apply them across the entire system. That’s problematic.
Ross: I’m sure it’s one thing to get all these folks in a room and focused in advance of a start-up, but once things are going and maybe you’re adding additional assets down the road, it’s only more difficult to get all the right people in the right place and have the right conversations.
Russel: Yeah. The folks that are building facilities actually have an advantage over the folks that are trying to retrofit this into facilities that exist. Of course, at this point everybody has something in place. The issue becomes more about, how do I take what I have in place and make it more effective?
Ross: I think that’s a great segue. We’ve been talking about challenges. One of the things we want to talk about, as well, is opportunities. What out there can folks be proactive about doing to make their operations more effective, more compliant, more safe?
What comes to mind, for you, when you think about folks taking the next step and diving into alarm management as it relates to opportunities?
Russel: I think that one of the big things is when you do a good job of alarm management, you accomplish two things. First and foremost, you make the workload in the control room at the console more meaningful because alarms have meaning. I don’t get a lot of them, so when I get one I’m paying attention and doing something. That’s the first thing.
The second thing is, if I’m doing a good job of alarm rationalization, I’m actually putting together guidance for the controller about how to respond to every alarm in my system. They know, here are the things that could be the root causes. This is what you check first, second, and third. This is how you run it to conclusion.
I think the control rooms that do this best are the ones that are able to quickly and effectively make small, incremental changes to their alarm response procedures. When anybody who’s working in the control room identifies something that’s less than optimal, they have the opportunity to offer a change. That change gets worked through a process.
The folks that are going to see this, the ones that are going to know what needs to be improved, they’re the ones sitting at the console seeing the alarms be raised. That actually makes your control room more effective.
I think there’s another major opportunity. That is in broadening the range of responsibility for the control room. If the control room has more information, has very well rationalized alarms, then they can actually control more assets more effectively and they can control those assets more deeply, meaning I’m actually going to use the automation to make those assets operate more effectively.
That creates a lot of opportunity, a lot of opportunity for cost savings, and production improvements, and throughput improvements, and all that kind of stuff. I’m just talking about in the way I manage my alarms.
Typical alarm response is shut down. What you really want is make adjustments and then if you can’t correct, shut down. That can make a huge difference in a company’s throughput.
Ross: There’s a few things. All of that, I think, resonated with me. In part, just in terms of how I use alarm manager software to support a lot of our customers and their alarm management programs. The way that we first do the rationalization, but we look at these, we call them configuration KPIs, to understand, based on priority, the distribution of their alarms in their system.
Trying to focus on not being top-heavy. You don’t want to have but a small percentage of your alarms as critical alarms. When you look at those configuration KPIs versus what we would call activation KPIs, the alarms that are actually occurring in the control room, there’s a causational relationship between the way you rationalize and your controller’s experience.
As a byproduct of that, there’s a causational relationship to your controller’s effectiveness. The better you are at being able to rationalize your alarms…To your point, it’s not only offering guidance to your controller, but it’s making them more effective in the way that they’re managing those alarms. In turn, that helps with the reliability of your equipment.
Russel: I think there’s two things I’d comment about that, Ross. One is that, really, you don’t want your controller’s job to be to respond to alarms. You want your controller’s job to be, how do I accomplish my business objectives more efficiently and effectively without doing any harm?
That’s really what you want a controller thinking about, not about responding to alarms. To the extent you can get them to that higher-level thinking quicker, they’re going to be more effective. They’re also going to find their job more engaging.
The other thing I would say, and this is subtle. It took me a while. When I first started learning alarm management, it took me a while to snap to this. You do not control alarm activation. The process controls the alarm activation.
What I control is the rationalization, but I analyze the activations to make decisions about what changes I should make in my rationalization. I include in rationalization where I set and how I place my set points.
I’m going to do these reviews of activations to see what I need to change in my rationalization. It took me a while to snap to that. I guess for people that do automation and have been in control rooms for years, that might be intuitive, but I had been doing that for years and it wasn’t intuitive for me. It took me a while to get there.
I think that historically we use alarms as a way to say, “I’ll just put an alarm on that so that way the controller will know about it.” That’s not really the right way to use alarms. That should be done in the HMI.
Ross: Very interesting. I knew we were flipping the script, but I’ve certainly been learning a whole lot.
Russel: I feel your pain, Ross. I feel your pain. [laughs]
Ross: I hear you.
Maybe something I know a little bit more about is the CRM Rule and what it has to say about alarm management. I think there’s challenges to compliance as there is with challenges to the operation and the set-up that you’ve been describing.
Once all of that work’s done, once the rationalization process is complete, and you’re focusing on your ongoing activities, and not necessarily in terms of what the controller is doing, but making sure that your program is improving.
PHMSA’s laid out several different things that they would expect you to do. One of those is your monthly alarm reviews. A lot of folks, you’ve got to be careful because the low-hanging fruit in that conversation is just looking at your KPIs and identifying your bad actors.
From a documentation standpoint PHMSA’s also expecting that you would be looking at all your points taken off scan, and those that have been inhibited, or where you’ve generated false alarms, had forced or manual values for periods of time exceeding that required for associated maintenance.
I’ve memorized all of that because I’ve had to say it so many times.
Ross: The thought there is that you don’t want to go…If you’re having to inhibit these alarms or if you meet any of those other criteria, that you’re not inhibiting them so long that you don’t wind up returning them to service. Typically, we’re putting a suggested cap on that when we’re writing policy.
What’s even more important about that is building the processes to ensure that the control room is working with the SCADA, and the automation team, and whomever else required to get those points turned around.
Russel: I think you’re right on it, Ross, at least from my experience. I think that the monthly analysis once a control room starts developing that rigor and they’ve got good analytical reports, that most control rooms like that activity because they see things and identify things that they can modify and improve.
They like that activity. That’s pretty easy to get them to do. I think the challenge from a regulatory compliance standpoint is somebody’s got to document that so that you have a record that it occurred. That’s a little different thing.
I think where people have a little bit more challenge, and it’s probably because this doesn’t happen as frequently as the annual reviews. You’re required annually to do a program effectiveness review. You’re required annually to do a workload review and make sure that you have time to effectively and adequately respond to alarms.
That’s actually in the fatigue management part of the rule, but it’s really more an alarm management requirement. Those are a bit more challenging because what really drives alarm management program effectiveness, what is it I’m trying to accomplish there? It’s a bit more challenging.
Plus, those are pretty heavy lifts. There ought to be a team of people looking at it. There ought to be a report. It should be circulated. There should be actions coming out of that. Those kinds of heavy analytical reports are often hard to get done, and get done on time, and do well.
Ross: I think that they are intimidating at times. Not to mention that you also have your annual set point and alarm descriptor review. There’s three or four that all have to get done. You mentioned having a team involved.
I think that’s incredibly important because they are away. They do take up some time to do. Your control room manager, if they’re tasked with doing it, it’s always the case that the control room manager has more tasks to do than there are hours in the day.
One of the things that I’ve encouraged in the folks we work with is if they do have, perhaps, some lead controllers or maybe a more veteran controller, that they work with that controller and get them educated on all of the requirements of alarm management, the specific company philosophies on alarm management and what have you, so that that person can then become the alarm steward for the control room.
Then, they can, in turn, take some of the responsibilities around performing these monthly reviews, performing these annual reviews, make sure that they’re documented effectively, and that the whole team, not just in the control room, but, like you said, in SCADA and automation, what have you, that they’re all pointing in the right direction and focused on continuous improvement.
Russel: I think that’s exactly right. I also think that when you talk about the alarm steward, that job is bigger than just the control room. That conversation has legs out into the field. It has legs into facilities and how facilities are operated. It has legs into your overall safety program.
One of the things you need in a good alarm steward is somebody who can drive the program. Do some leadership beyond just the control room.
Ross: That’s a really important point because you’re talking about a particular skill set. The other thing that person’s got to be able to do is manage, essentially, your list of deficiencies.
All the things you’ve identified in performing your monthlies and your annuals, or really, just those things that you notice on an ongoing basis, that fall into this list of deficiencies or issues that need to be improved upon or where corrective action’s required. Then, you have to drive it to conclusion.
Russel: Yeah, they’re all actions that fall in your continual improvement program. Exactly right.
Ross: That person has to be able to drive those tests to conclusion in an effective way. Part of that’s utilizing all those other teams.
One of the last things I want to talk about is we’ve discussed alarm management, a little bit about what it is, the challenges, the opportunities with regulatory elements. Certainly, we could do a whole podcast on just the regulatory elements of alarm management. Not to give you any ideas.
Russel: [laughs] I heard you. Who heard Ross volunteer? Was it just me?
Ross: These are a lot of fun, so I don’t mind too much. One of the things I want to make sure we do before we wrap up today is try to paint a little bit of a picture for folks. I do agree with you. I think most everyone has some form of a program now.
If you were going to start from scratch or if you were going to issue some advice for those looking to maximize the effectiveness of their program or build one, what does that look like to you? What should those people be thinking about? How can they take things to the next level?
Russel: Thanks for that question, because this gives me an opportunity to philosophize a little bit, if you will. I want to make a caveat statement that I’m not a guy who has been in operations leadership. I’ve certainly worked closely with very many and I have a great deal of understanding about pipelines and how they operate, but I want to tee it up as…
What I’m going to say is what I would do might be a little outside of what the industry would do. Having made that statement, here’s what I would say. If I were doing a new midstream start-up and I were building pipelines and the related facilities, I think the big thing I would do is I would look at my PHA program and I would look at my alarm management program and figure out how to glue that together with the construction program.
In other words, I would try to build the assets so that we could operate them effectively. I think what happens a lot of times is we tend to build assets so that we can get them up and running. Then, we do other projects to optimize the way we operate them.
I really want to take a look at, “Yeah, but here’s how we’re going to operate this facility so that it stays up, and operates, and operates safely.” That’s an alarm management question. Still do all the PHA stuff. I’d try to glue that together.
I’ve tried to look at how I organize my team and I organize my operations so that the alarm management and PHA processes work together as the core operational review as I’m learning and making changes. I think that’s the big thing I would do.
Ross: Would it make sense to establish a joint alarm philosophy and use that document, that process, to establish buy-in from each of those groups?
Russel: I’d answer that question, “Probably,” but I might answer it a little bit differently. What I would look at is that when I’m looking at my regulatory, my governance program and I’m looking at the policy and process I’m designing around construction, and modification, and operation of assets, that I would embed that into that higher-level policy.
I’d actually want to raise it up so that that’s something that the operations leadership, the chief operating officer, is driving. I just did a…This is kind of a sideline, but I just did a recording. I don’t know right now if it’s going to come out before or after this one, but with an operations executive.
He talked about how he designed the company and how they approach things so that they were driven commercially towards operations excellence. That is actually a really…When you start raising this issue up to the level I’m thinking about, you’ve got to look at, “What are the commercial impacts of what you’re talking about?”
To me, that’s the answer. I’d take the PHA and the alarm management process. I would figure out how to make those things go together. I’d have them fit at a high level in my overall governance process.
Ross: Excellent. Russel, I think this was incredibly informative. I appreciate you having me back and letting me be a guest, or maybe letting you be a guest on your own podcast. Flipping the script was a lot of fun. It was nice being in the driver’s seat.
Russel: It was nice to be the expert for a change. Ross, I really appreciate it. I want to give you credit as being the guest, but for the listeners, I’d just say thank you. I really enjoyed doing this, as well. It was a nice change of pace, for sure.
I hope you enjoyed this week’s episode of the Pipeliners Podcast, and our conversation with Ross and myself. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing. If you would like to support the podcast, please leave us a review on Apple podcast or on whatever app you use on your smart device. You could find instructions at pipelinepodcastnetwork.com.
Russel: If you have ideas, questions, or topics you’d be interested in, please let me know either by filling out the form on the Contact Us page at pipelinepodcastnetwork.com, or you can reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.