On this week’s episode of the Pipeliners Podcast, host Russel Treat is joined by Ross Adams of EnerSys Corporation to discuss operations effectiveness – what it is, how to define it, and how operators should be thinking about it. 

Natural Compliance and Operations Performance in the Control Room Show Notes, Links and Insider Terms

• Natural Compliance – An operating approach where compliance is a byproduct of doing the right work the right way; required records and documentation are automatically generated through normal operations rather than through special compliance efforts.
• Operations Performance / Operations Effectiveness – The ability of an organization to consistently perform work safely, efficiently, and effectively in alignment with organizational objectives, supported by continual optimization of processes.
• Operations Excellence – A way of working and thinking rather than an end state, where systems, processes, and execution are continually improved to achieve safe, efficient, and effective outcomes.
• Program Management – The governance layer that establishes policy, objectives, and direction; it defines what an organization is trying to achieve and provides the foundation for processes and execution.
• Process Management – The discipline of defining, monitoring, measuring, and improving how work is performed to achieve desired outcomes; focuses on responsibilities, outcomes, and performance measurement.
• Task Execution – Day-to-day operational activities performed by individuals (in the control room or field) that generate records and outputs; tasks are the tactical execution of processes.
• Policy – High-level declarative statements that define organizational intent and expectations, such as stop-work authority or safety commitments.
• Process – A structured approach that defines who is responsible, how work is done, and what outcomes are expected; includes feedback loops and performance measurement.
• Procedure – Step-by-step instructions for an individual to complete a specific task (e.g., “do X, Y, Z”); procedures support execution but do not define outcomes or improvement.
• System of Work – A collection of tasks and workflows focused on completing activities, often without evaluating whether those activities achieve desired outcomes.
• System of Processes – An integrated approach where work is treated as a process with defined objectives, metrics, feedback, and continuous improvement.
• Pipeline Safety Management System (PSMS) – A structured management framework for identifying and managing pipeline safety risks, emphasizing leadership, risk management, and continuous improvement.
• API RP 1173 – An American Petroleum Institute recommended practice that defines requirements for Pipeline Safety Management Systems, emphasizing systematic risk management and continuous improvement.
• Operations Management System (OMS) – A management framework that integrates policy, process, execution, measurement, and continuous improvement across operational disciplines.
• ISO 9001 – An International Organization for Standardization quality management standard that provides a framework for process-based management and continual improvement.
• Annex SL – A common high-level structure used by ISO management system standards to align requirements across disciplines such as quality, safety, and operational performance.
• Continuous Improvement – An ongoing effort to improve processes, outcomes, and performance through measurement, analysis, and adjustment.
• PDCA (Plan–Do–Check–Act) – A continuous improvement cycle used to plan work, execute it, evaluate results, and make adjustments; foundational to OMS and PSMS approaches.
• Key Performance Indicators (KPIs) – Quantitative and qualitative metrics used to measure whether processes are achieving desired outcomes and objectives.
• Total Quality Management (TQM) – A management philosophy focused on continuous improvement, process control, and quality, forming the foundation for modern quality and safety systems.
• W. Edwards Deming – A quality management pioneer whose principles underpin TQM, continuous improvement, and process-based management.
• Six Sigma – A data-driven methodology focused on reducing defects and variability in processes, referenced as an evolution of quality management principles.
• Control Room Management – The structured management of control room operations, including shift handover, alarm management, logging, and situational awareness.
• Shift Handover – A recurring control room process to transfer situational awareness, operational status, risks, and responsibilities between controllers.
• API RP 1168 – An API recommended practice addressing control room management, including requirements for shift handover records and situational awareness.
• Situational Awareness – A controller’s understanding of the current operating state, risks, abnormal conditions, and priorities necessary for safe and effective operation.
• Alarm Management / Alarm Analytics – The analysis and management of alarms to reduce alarm volume, improve alarm quality, and ensure alarms are meaningful and actionable.
• Management of Change (MOC) – A formal process used to evaluate and control changes to processes, systems, or operations to prevent unintended safety or operational impacts.
• Maturity Levels – A conceptual scale used to describe how advanced an organization is in implementing systems, processes, and continuous improvement (e.g., procedures defined vs. processes optimized).
• Stop Work Authority – A policy granting employees the right and responsibility to halt work when unsafe conditions are observed.
• Compliance View vs. Operations View – Two lenses for evaluating work: compliance focuses on records and regulatory adherence, while operations focuses on achieving safe, reliable, and efficient outcomes.

Natural Compliance and Operations Performance in the Control Room Full Episode Transcript

Russel Treat:

Welcome to the “Pipeliners Podcast,” episode 378, sponsored by EnerSys Corporation, providers of POEMS, the pipeline operations excellence management systems, operations and compliance software for the pipeline operator to address safety, program management, control room, management and field operations. Find out more about POEMS at enersyscorp.com.

[background music]

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. I appreciate you taking the time, and to show the appreciation, we give away a customized YETI Tumbler for one listener every episode. This week, our winner is Doug Sauer with Phillips 66 pipeline. Congratulations, Doug. Your YETI’s on its way. To learn how you can win this prize, stick around till the end of the episode.

This week, Ross Adams returns to the podcast and we visit about operations effectiveness, what it is, how to define it, how to think about it. Hey, Ross. Welcome back to the Pipeliners Podcast.

Ross Adams: Hey, Russel. How are you doing?

Russel: I’m in the middle of trying to articulate what is the difference between policy, process, and procedure.

Ross: How’s it going for you?

Russel: [laughs] That’s why I got you on because that’s what we’re going to talk about. I would say that I’ve got myself stuck in a circular conversation, and it’s causing a lot of frustration for me and others.

Ross: I can understand that. I see that as a common pitfall for many in a lot of the work that we do and probably one for myself as well.

Russel: What’s important to understand about this conversation is we have been focused on natural compliance for about 15 years and building up capability to do natural compliance. When we started all this, we didn’t even know what natural compliance was, but we’re pretty clear about it at this point. I’ll ask you the question, how would you define natural compliance?

Ross:

The simplest way to define it is you’re doing the work you ought to be doing anyway, and the records, the documentation, the things that you ought to be accomplishing for the sake of compliance are happening.

You do the work, and compliance is just happening. It’s a byproduct of the approach that you’re taking, the systems you’re using, processes that you’ve put together. It’s inter-working the compliance into making it the output of all that you do.

Russel: What’s necessary in order to implement natural compliance? What does that take?

Ross:

[laughs] If I was given a sales pitch, we have a nice little triangle diagram and everything to show for this. I talk about this all the time. We talk about systems, and three types, program management, process management, and then task execution. It’s important to frame those three in that order because there’s a starting point.

We start with program. It’s governance. It’s the solid foundation by which we are going to do all the things we do in our course of business. Once we establish that policy, there’s process that rolls out of that. I’ve established where I want to go. Now I need to orient myself to how I’m moving in that direction.

Then there’s task execution we talk about a lot, which is your day-to-day. It’s the things that out of which comes natural compliance. It’s all the things you’re doing, whether in the control room or out in the field or wherever, that is small, tactical tasks often that generate records that are getting to get pulled up in an inspection or what have you.

Program management, process management, task execution in that order, all of that comes together to build a solid approach for natural compliance.

Russel: I would argue, or I would assert that gravity, and what I mean by that is natural behavior of human beings, will take you to writing a program and doing tasks and skipping process. Would you agree with that assertion?

Ross:

I might even expand upon it. You’re right. I also think that gravity, and often that gravity looks like a boss that’s demanding something or some operational situation that necessitates something, but gravity takes us to task, and task in isolation from process and program.

I do a lot of small things tactically, if you will, devoid of awareness to either my strategy or my governance or the direction in which we’re seeking to head as a team or as a company.

Russel:

That’s exactly right. I’ve been working on how to language this. How do you explain what operations excellence is? Where does it come from? How do you get to it? I don’t think operations excellence is an end state. It’s a way of working, a way of thinking, a way of approaching what you do.

I want to try this on, but I would say that operations excellence is when your system is being continually optimized to perform your work safely, efficiently, and effectively to accomplish your organizational objectives. Now that’s a lot of words. Sometimes when we think about system, we tend to think about software and workflow. What I’m talking about is, what is my process system?

What are my processes, and how are they implemented and monitored and improved? Because that’s the thing that it’s hard to get to. In a normal operations, it’s hard to get to that where you have the bandwidth to actually look on improving process. Would you agree with that definition? Does that definition makes sense? Do you have questions about the definition?

Ross:

I have a lot of questions, but am I related in a particular way? We were doing a meeting one time with an outfit, and one of the gentlemen on the call used to work in nuclear submarines. I tell the story all too often now. We were presenting our approach, and he was talking about how in nuclear subs, you’re always getting ready for the next inspection.

You never have time to optimize or improve your process and your focus on safety. What he was expressing and with a focus towards what we have to offer in terms of solutions, but in his context, he was suggesting that that’s true in pipelining as well, and that you need systems to support the ability to then continuously improve.

Get you out of this rut of just focusing on the tasks, just focusing on the next thing that’s coming up in this do list or the next inspection or the next deliverable. What I hear you saying you’re describing, and we ought to connect the dots a little bit better, but what I hear you describing is the focus and maybe even the means of elevating out of that rut and into a better future, if you will.

Russel:

That’s right. When we first started working together, we were pretty much exclusively focusing on control room management. The issue there was people didn’t have plans, they didn’t have procedures, they didn’t have records. Now everybody has something. It may not be efficient, it may not be effective, but everybody has something.

What we were hearing a lot of is the pain was, “Oh, my gosh. The effort to prepare for the inspection is excruciating. I got to put six people in a room for six weeks to get ready.” That kind of thing. We said, “Well, there’s a better way to do this. If we’ll build everything right, the inspection should be a normal course of business.” We’ve had some success with that.

The problem is, once you have that in, it becomes about doing the work and not about looking at and improving the process. With pipeline safety management, and API 1173, and all that’s being driven out of that, we’re beginning to look at how are we actually going to get to the results.

I’m advocating that the way you do that is you start thinking about this as a system of processes versus a system of workflows.

Ross: Tell us more about that distinction, a system of processes versus a system of workflows.

Russel:

If I’m thinking about, again, I’m going to use the control room because it’s what I know the most about in this context. There’s a certain set of things that I do on a recurring basis. I’m doing shift handover two times a day. I’m doing log entries every day. I’m doing alarm analytics once a week or once a month. Those are all activities that I’m doing.

If I’m doing those activities, I might be improving my alarming, but am I really improving what outcome I’m trying to get to? I know this seems a little squishy when I talk about it, which is why we’re having this conversation. You’re helping me get the squishiness out.

If you think about a workflow like I’ve got to run these reports, I’ve got to do this analysis, I’ve got to come up with a list of corrective actions, I’ve got to work those corrective actions, that is a system of work.

A system of process would be I’m going to do alarm analysis to improve my operation safety, and the things I’m looking for is I should have fewer alarms, and the alarms I’m getting should be more meaningful.

Then I have a mechanism or a process where not only am I doing that work, but I’m also looking at the work I’m doing, and I’m asking questions about, “Am I getting to the objective, or am I just doing the work?”

To take that one step further, if I think of compliance as a system of work, operations excellence would be a system or process that’s analyzing that work and determining is that work getting me to the result I’m looking for.

Ross: Does that suggest an assessment of KPIs, or what’s that assessment look like?

Russel:

Definitely, it would include KPIs. Actually, I have to go back. My MBA was a quantitative MBA, and we did a whole bunch of stuff in total quality management, which comes from Deming and has evolved into things like Six Sigma and other quality and safety processes. It’s the base science behind all that.

One of the things that you would do is you would take a manufacturing line, you would break it down into its sub-processes. I’m feeding in metal and rubber into one end of a process, and at the other end, I’m getting motor cars out.

There’s a whole bunch of sub-processes. There’s sub-processes for the engine, there’s sub-process for the suspension, there’s sub-processes for the battery, there’s sub-processes for sourcing materials, and all that has to come together. With each of those nodes in the process, you look at specific KPIs.

One of the things that process management is doing is they’re asking the question is, “Is that the KPI we should be optimizing for?” You would have a KPI, you would look at it, you would optimize it, that would be part of your process, but you would also be asking the question of, “Well, should I be looking at something else?”

Particularly, if you look at a particular machine, there’ll be things like cycle rate in the machine. Can I improve the cycle rate? If the cycle rate goes up, does my defect rate go up? Can I lower the cycle rate and reduce the defect rate? Which is the number that I need to look at?

A big part of the process is knowing the KPIs and wondering about it and analyzing, is that the right KPI now. If you think about the alarm example, it usually starts with just getting my total number of alarms down. Once you get that done, then it becomes about, what alarms should I be getting, or how do I make my alarms more instructive versus I have a high pressure too. I’ve got a blocked filter.

Ross:

One of the great things I love about coming on the podcast, Russel, is sometimes I have something to offer, and other times, I get to sit here as student and soak it up. I’m curious, and this is maybe a little bit of a curve ball, but the last time you and I were teamed up on this, we were talking about OMS programs, operations management systems.

How would you connect the dots between what we talked about last time and this time in OMS, and then this operations performance approach focusing on process?

Russel:

They’re the same thing, but it’s a good question because I don’t know if I could articulate it very well. I’ll give it a stab. We’ll see how it works.

An OMS is an operations management system. There’s good materials available from the International Standards Organization, ISO, and ISO 9001, which is a quality management standard, and what’s called Annex SL, which is a whole family of standards that are built in alignment with 9001 for things like operational technology, asset integrity, operations performance, and so forth.

When you’re building an OMS, what you focus on first is what are the policy statements? What are the declaratives in pipelining things like everybody has stop work authority. That’s a global policy directive. Then that has to be articulated into, what does that mean in different domains? It’s one example, but you’re looking at a system of policy statements.

Then the thing that makes an OMS real is the requirement for continuing improvement. The first section is, here’s all the things you have to do. It’s defining these are the processes we should be executing.

Then behind that, you’ll have here’s how we’re going to do management of change, and here’s how we’re going to do continual improvement because without internal inspection and review and analysis, you’re never going to have an OMS implemented. You’ll have a system of work, not a system of processes.

To get to a system of processes, you have to be analyzing the work as a process and then looking to improve it. One of the things that Deming said, and he’s very famous for this quote, was, “If you can’t describe what you’re doing as a process, you don’t know what you’re doing.” That’s a really deep comment.

Ross:

It may speak to maybe my next question for you, and I asked this last time as well.

If I’m in a company, put myself in the position of perhaps a lot of our listeners, and I’m like, “Hey, we’re chasing our tail a little bit. We do a lot of tasks, and the work we do is good, but it seems to be sporadic. I’m playing a little bit of Whack-a-Mole, and it’s over here and it’s over there, but I don’t know that we’re moving the ball down the field.”

This quote from W. Edwards Deming, this may suggest the answer or the place to start exploring improvement in this way is to start asking the question what’s our end goal, and how do we establish process to get there? Is that what you’d recommend, or what are your thoughts there?

Russel:

Good question. Yes, you have to get clear what are my processes, and you have to get clear how they’re put together. That’s where it’s got to start.

In the early days of TQM and going into manufacturing and trying to improve quality, the first thing they would do is they would study the factory and understand what are the processes inside this factory. That was always the place they started. I’ll ask you the question, what would be an example of a process in the control room?

Ross:

There’s more than a few. I was looking at today. We’re helping a customer get ready for an audit. Shift handover is a great example. It’s a process that, as you mentioned, repeated twice a day. There’s a desired outcome looking at it through a couple of different lenses.

From a compliance standpoint, I have to generate a record that demonstrates that I’ve communicated situational awareness through API RP 1168. From an operational standpoint, I have to achieve that passed down situational awareness, communicate nominations, status, abnormal operating conditions, risk. Risk speaks to safety as well.

There’s a safety leg or a lens to this and focusing on where is the risk or the AOCs? What are you picking up that I’m putting down? All of those are a byproduct of a successful handover process.

Russel: If you can try to get to a higher level and tell me what are the outcomes that you’re trying to get to for shift handover.

Ross: Effective handout of situational awareness and then adequate record keeping to prove that that occurred.

Russel:

I would argue that that’s a compliance view. From an operations view, there’s also a understanding the current operating state in order to hit company objectives, schedules, deliveries, that sort of thing, and anything that’s critical to safety, which you addressed.

I’m putting a little different spin on that. What would be some examples of KPIs you might monitor in order to determine if you’re accomplishing those objectives or those outcomes?

Ross:

One easiest is, did it occur? Did it occur in the time frame that is allotted by our governance? Was it sufficient in terms of the level of information being passed down? You can look at that in a couple of different ways.

Track the duration that the handover lasted is one way, and there’s different means of accomplishing that, or even developing some metrics for spot-checking the quality of the information being passed down as well. Just to name a couple.

Russel:

What you’re driving at now is you’re beginning to define a process. I’m going to do the work, I want to do the handover, and then I want to get some quantitative and qualitative KPIs that I can use to determine how well I’m doing. Then I’m going to look at those KPIs over time and I’m going to look at making changes to the process to improve those KPIs.

That is process, because to do that, you got to get really clear about what am I doing? What is my expectation? In other words, what does quality look like, or what does completion look like? What does performance look like? Then I have to have way to measure that performance. Then, as I start looking backwards at that, what happens is I’m analyzing my process.

I’m also analyzing my measurement, what I’m measuring, how I’m measuring it, and I’m looking to get to better answers or better outcome, improve the outcome. Fundamentally, the place that we’re at as an industry, I’ll articulate this. Been talking about control room. I want to cast a little broader net.

A lot of places, they’ve got their compliance programs in place, they are putting in place pipeline safety management, and they’re at a level two to maybe two-and-a-half maturity, which means they have procedures defined, but I don’t think very many operators yet are actually getting to the level of process.

This brings up an interesting question, and that is, what is the difference between process and procedure.

Ross: [laughs] I live in a world that skips process. We do governance really well. We do procedure really well. I would suggest we do continuous improvement really well. I, along with others, I’m sure are struggling with this concept of process. The more that you elucidate, the more I learn.

Russel:

I would say that one of the challenge was this is this language will be different from organization to organization. You can go on the website and you could ask what’s the difference between policy and process, and you’ll get 100 different answers.

What I would say is, process is who’s responsible, how’s it done, and what should the outcome be? Procedure is for a single person, do X, Y, Z, done.

Ross: That makes sense. [laughs]

Russel: [laughs] Come back to this in 30 minutes and see if we still have the same answer. That’s the challenge.

Ross: Like math homework back in the day.

Russel:

Yeah, exactly. Fundamentally, that’s the difference. We’re going to be talking about this at API. We’ve got a couple of different presentations where we’re going to talk about this in a little bit more depth.

The question becomes is, how do I get to process? Because when you think about pipeline safety management and you think about the PDCA, the plan, do, check, act or adjust, depending on which word you like best. If you think about that cycle, that infers a generic process. For everything we’re doing, we should be running that cycle.

Getting to the point that we’re taking that whole plan, do, check, act, cycle and understanding how to implement it, and that’s the purpose of an OMS is to define this is how we’re going to do it organizationally at the OMS level and then this is how we’re going to do it in each discipline, control room, integrity management, public awareness, and so forth.

Ross: That’s a big vision. I’m listening to you, I’m thinking about, and I don’t know if people say it’s a Navy SEAL saying or who knows what, but the adage around you don’t rise to the opportunity. You sink to level of your training. I [inaudible 25:50] you. You might say we sink to the level of our process.

Russel: Oh, that’s good. Can I quote you on that?

Ross: We’ll make T-shirts.

Russel: Yeah, we’ll make that a Ross’. [laughs]

Ross: Oh, gosh. Nobody deserves. Maybe we add jacuzzis or something at API.

Russel: That’s right. What did you say? You don’t rise to the level of the opportunity. You sink to the level of your training.

Ross: Yeah, but process, not training.

Russel: That’s a battlefield analogy. What it’s saying is when the heat is on, you do what you know how to do instinctively.

Ross: Right. For a lot of folks that we work with, that’s go back to tactical. Let’s go back to point and shoot, get things done.

Russel: Yeah, get the work done. They’ll fall behind.

Ross: The reality is that there’s a lot of use for that, and companies can make money doing that.

Russel: It’s critical, too. You have to do that.

Ross: Yeah, absolutely, but to move the needle. Of course, where you and I are both focused on having a particular impact on industry, having more of a process-oriented mindset that’s tied into continuous improvement, tied to KPIs, tied to strategy. That’s part of the thing is, definition-wise, I think a lot about processes strategy.

Russel: A lot of people would put those two ideas together, for sure.

Ross: They’re different certainly.

Russel:

Strategy is what do I need to do. Process is how am I going to get there. Then there’s lots of other things that have to happen. I still got to do all the work planning, I still got to build my systems, and do all those things. Strategy is I want to improve the quality of my auto production so that I go from this many customer complaints to this many customer complaints. That’s a strategy.

Process is here’s the things we’re going to do to make that happen. Then execution is all the procedures and actual running of the machines and the work to get that done.

Ross, I know I’m challenging you to think outside of the box you live in. I appreciate you coming on here and having the conversation with me. I hope that the listeners find this helpful.

This is a conversation we’re trying to work through as we try to mature what we’re trying to offer to the industry in terms of helping them operate more effectively, operate more safely, that sort of thing. Getting clear about this is important.

Ross: I appreciate that all your listeners got to hear our typical Friday night chat on the podcast.

Russel: The only thing we did wrong is we’re not having the cocktail until after the chat. If we’d had the cocktail before the chat, it might have been a more interesting chat to listen to.

Ross: Might have been. Next time. At API, at least.

Russel: Yeah, absolutely. Thanks for coming on. I appreciate you.

Ross: Sounds good. Thanks for having me.

Russel:

I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Ross. A reminder before you go, you should register to win our customized Pipeliners Podcast YETI Tumbler. Simply visit pipelinepodcastnetwork.com/win and enter yourself in the drawing.

[background music]

Russel:

If you’d like to support this podcast, please leave us a review on Apple Podcast, Google Play, or Spotify. You can find instructions at pipelinepodcastnetwork.com.

If you have ideas, questions, or topics you’d be interested in, please let me know on the Contact Us page at pipelinepodcastnetwork.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.