This week’s Pipeliners Podcast episode features first-time guest Sheila Howard of PI Confluence discussing process management applied to pipeline safety management.
In this episode, you will learn about the key differences between processes and procedures, how to optimize the human element of pipeline process quality management, how process quality management can be integrated into day-to-day pipeline activities to ensure that the system and processes are safer, how to establish KPIs as part of a Pipeline SMS program, the future of PSMS to support zero incidents, and more valuable topics.
Pipeline Quality Management: Show Notes, Links, and Insider Terms
- Sheila Howard is the VP & Software Solutions Manager for PI Confluence. Connect with Sheila on LinkedIn.
- PI Confluence (PIC) provides a complete GMS (Governance Management System) that manages process, workflow, communications, and information exchange among stakeholders to help operators align with the fundamentals of Pipeline Safety Management Systems (PSMS).
- Process Safety Management (PSM) is a set of interrelated approaches to managing hazards associated with required processes in the pipeline industry. PSM is intended to prevent incidents and reduce the frequency and severity of incidents resulting from the release of product.
- Pipeline SMS (Pipeline Safety Management Systems) or PSMS is an industry-wide focus to improve pipeline safety, driving toward zero incidents.
- The Plan Do Check Act Cycle (Deming Method) is embedded in Pipeline SMS as a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement and learning.
- Distribution Integrity Management is looking at the various threats that can cause an unintended release of gas from the pipeline.
- Integrity Management (Pipeline Integrity Management) is a systematic approach to operate and manage pipelines in a safe manner that complies with PHMSA regulations.
- DIMP (Distribution Integrity Management Program) activities are focused on obtaining and evaluating information related to the distribution system that is critical for a risk-based, proactive integrity management program that involves programmatically remediating risks.
- Aldyl A is a type of plastic polyethylene (PE) pipe developed by DuPont that was designed to be inserted directly into old pipe. However, early editions of Aldyl A were determined to be a potential hazard affecting gas pipelines.
- MOP (Maximum Operating Pressure) is the maximum operating pressure at which a pipeline is designed and qualified to operate. Operators are recommended to implement processes that identify and maintain the MOP of pipelines to support pipeline safety.
- ILI (Inline Inspection) is a method to assess the integrity and condition of a pipe by determining the existence of cracks, deformities, or other structural issues that could cause a leak.
Pipeline Quality Management: Full Episode Transcript
Russel Treat: Welcome to the Pipeliners Podcast, episode 170, 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. I appreciate you taking the time. To show that appreciation, we give away a customized YETI tumbler to one listener each episode. This week, our winner is Raymond Reese with the Transportation Security Administration. To learn how you can win the signature prize, stick around till the end of the episode.
This week, Sheila Howard with PI Confluence will be joining us to talk about process management applied to pipeline safety. Sheila, welcome to the Pipeliners Podcast.
Sheila Howard: Thank you for having me, Russel.
Russel: I brought you on to talk about the pain of process versus the possibility of process, which has been a theme of a number of the conversations we’ve had on the podcast within the last few months. I’m interested to get into this, but before we do, maybe you could give us a little bit about your background, and then what’s your role in the pipeline space.
Sheila: My background is in electric utility primarily. I started my career at a little a&e firm, and then spent a good number of years at Detroit Edison 15 to 20 years there. I traveled around a little bit, wanted to go into warmer climate. Went down to Texas and worked at a brand-new, coal-fired power plant down there.
Had an opportunity to get more into mechanical integrity, quality assurance, reliability arena with DuPont. I took the leap and went up to Buffalo, New York — back into the cold — and spent some time up there about six years. I had an opportunity to come work for PI Confluence in more of a computer space, which is my educational background.
I do more of the process workflow and process quality management within the pipeline industry currently today.
Russel: Interesting. How long have you been doing the process management stuff in pipelining?
Sheila: About three years now.
Russel: How does that relate to your experience in electric utility and the other things you’ve done?
Sheila: Primarily because everything is a process. We all deal with procedures, objectives, and certain ways we need to get things done. There’s a lot of overlay with it.
Then, with the quality assurance and the mechanical integrity piece, I just dealt with much smaller pipes in chemical plants versus the bigger pipelines that I work with now but a lot of the same objectives, a lot of the same inspections, a lot of the same tests, things like that.
Russel: Cool. Talk to me. How would you define process?
Sheila: Process is a series of tasks to actually meet an objective that you’re trying to obtain.
Russel: A series of tasks to meet an objective. That seems painfully obvious. What am I missing?
Sheila: Usually, people get confused between processes and procedures. People assume a procedure is a process. It’s not. Procedure tells you how to do something. A process is the bigger picture, all the different steps that it takes.
Each step of the process may have a procedure associated with it, but there’s an overall series of individual tasks in order to complete the primary objective, which is a process.
Russel: How does that relate to pipeline integrity?
Sheila: In pipeline integrity, we have a lot of the regulatory requirements that need to be met in order to satisfy the government. There’s a series of processes between your system knowledge and your threat risk analysis and your inspections, all those pieces tied together to be an overall, like for distribution, we called it the DIMP cycle. It’s your DIMP process.
Each process individually has different tasks to meet those different objectives. If you’re doing your risk analysis, for example, there are a series of tasks needed. You need your leak data. How do you get it? That’s a task to go get that leak data. Then you have to analyze your leak data. All those pieces together are the process to complete in order to have your full risk analysis.
Russel: Why is that so dadgum painful?
Russel: That’s really the material question I brought you on to talk about.
Sheila: What we seem to see a lot is there’s not necessarily clear ownership when you have these processes involved. There’s too many hands in the pot. Different people are trying to do different parts. It gets muddled at times. There’s the administrative load. We have to do our recordkeeping, our documenting, pieces like that.
Again, it’s just something that gets missed, or people don’t want to take the time to document everything that they’ve done. It’s usually a challenge. People find it painful. It’s a task that we have to actually show the value-added when you have all those pieces lined up and documented to be able to follow up in the whole Plan-Do-Check-Act cycle.
You can’t check something you’ve never documented. This gives you that ability to work through the process and then be able to refer back and look. The pain is too many hands in the pot, a lot of recordkeeping that people sometimes are challenged to find value in.
Russel: At least in my experience, people tend to spend a lot of time on the procedures. How do I accomplish this particular task? They tend to be pretty clear about that. What tends to get lost is the bigger picture. What do I have to do, and what am I trying to accomplish? When you get close to the boots on the ground and doing the work, that’s pretty common. It’s easy to understand why it’s so.
I’ve got this work I’ve got to do, so I’m doing the work. The analysis about the work is a separate task, if you will.
Sheila: Like a parallel process almost.
Russel: Exactly. That’s one of the big challenges, is that just the workload gets in the way. Then the other thing is it’s easy to become an expert in a task. It’s much more challenging to become an expert in a process.
Sheila: Usually because there’s just so many different areas with different tasks. It’s almost like you have to have that procedure nailed down in each one of those individual tasks in order to have the big picture of the process.
Russel: You talked a little bit about lack of clarity and ownership. Can you expand on that a little bit? What have you seen in that domain around process being painful?
Sheila: There are times when you’ll have new people that come on board, for example. They’re trying to fit in. Everybody’s busy learning and doing. Sometimes, it’s a challenge for them to understand what’s been done in the past or who owns which part.
Within a process, if you have it clearly defined, then it’s a lot easier to say, “Person A owns this part. Person B owns this part.” It helps clarify roles when you have processes detailed and lined out.
Russel: As I’m listening and I’m thinking to this, I’m thinking about a story I read. It’s a funny story. I want to see what your take is on this, and how this relates to process and procedure.
There’s a story about a commander that comes on a base. He’s new to the job. He finds out that there’s a permanent guard rotation assigned to guard a bench to make sure that nobody sits on this particular bench. He can’t figure out why people are doing that. He goes and he talks to those people, who say, “Hey. This was our job. They gave us this assignment, so we’re here to guard the bench.”
They talk to the sergeant. “Well, it’s a standing order. It’s been around for a long time.” “Well, who gave the standing order?” “I don’t know. It might have been the captain.” They went to the captain. Then they end up going to the previous base commander, who’s retired, and talking to him. The guy calls him up and says, “Why is that guard posted on that bench?” He says, “What, is the paint still wet?”
Russel: I think that’s what you’re alluding to, is that sometimes we get so busy just doing the job that we forget to take a look and ask the question, “Why are we doing this job? Is the job we’re doing still meaningful in the context of what it is we’re trying to accomplish?”
Sheila: Agreed. Processes shouldn’t just be laid out and ignored. The idea is that once you have the process laid out, documented, then there’s that whole check piece, where you go back you look. Did we get the outcome that we were looking to get? If people don’t know that answer, it’s really hard for them to find value in what they’re doing and why they’re doing it.
It takes those people, like in the story that you mentioned, that actually bring up the question to say, “Why are we doing this?” When you have the processes laid out and defined, then it makes it easier to understand the value and the end result because your outcome is what is expected.
Russel: Often the other thing that’s challenging about this is the outcome we’re trying to get to is something we’re trying to avoid.
Sheila: Correct. A lot of times it’s from a safety aspect.
Russel: That does tend to make things more difficult than an outcome I’m trying to get to, improve and reproduce.
Sheila: We had talked historically in the past about the Deming Model. The Deming Model is always talking about widgets. When we’re talking about something more abstract, how do you pinpoint that? How do you define what your objective is? How do you know you’re doing it right if there’s no outcome? Which is what you’re trying to get at.
Russel: Exactly. How do you accomplish that in the context of a safety program? How do you define and monitor whether or not you’re getting the outcome you’re looking for.
Sheila: Again, it’s clearly defining the objectives within that task. Your objective is clearly defined in your process. The tasks are stepped out to guide you to get to that completed objective or the process.
Russel: What might be a specific example from an integrity perspective of a outcome that you’re trying to monitor for or a goal you’re trying to accomplish? How do you break that out?
Sheila: For example, for performance, we have several processes. I’m going to refer back to the distribution cycle again within integrity management. If you go back to the DIMP cycle, the regulations say you need to do your threat assessment, your risk analysis, and then it jumps over and says, “Now, go fix something.”
There’s not really a clear definition of how or what you go fix. It just says, “Look at some things and then do something about something.” It’s not very clearly-defined sometimes.
Russel: It’s one of the challenges in a performance-based standard versus a prescriptive standard.
Sheila: Exactly. Where transmission’s more descriptive, the distribution’s a little bit more open-ended. How do you go from that system knowledge, threat, risk, performance, and then go fix? One of the things we always try to push is asking the people.
From a safety management perspective, go out to the field and talk to the people that are actually working and seeing the leaks and the problems out in the field because they are almost always something to do with it, what we call organizational bits. It’s human performance. It’s going to be training. Procedure is wrong. The equipment’s not effective. Something to that effect.
From a process perspective, we go and we still do our system knowledge, our threat, our risk, our performance, but then we actually take another step further from the safety perspective and actually go in and inspect or have investigations with those people in the field, then the boots on the ground, and understand and get that feedback from them.
If you show them, here’s what the data is telling us from our system knowledge. Here’s the five-year trend of what’s happening. ‘Do you have any input on how we can make this better? What can we do to fix it?’ And, we’ve seen a lot of great feedback. People have identified materials that companies thought were already eliminated, like Aldyl A. They thought it was gone.
They found additional Aldyl A in the field. It’s causing leaks but it’s being coded incorrectly. The process to actually go out, do that investigation and talk to those people in the field provides a lot of valuable feedback. Then, once we have all that feedback and information, then that helps the companies lean or gear towards more of, ‘What are we going to fix? Why are we out here? What are we going to do?’
That’s your continuous improvement. Once you identify a corrective action to implement, then we schedule a performance a year later. A lot of people miss that follow-up. People will come up with an idea that will say, we’re going to go remove all this Aldyl A.
We’re going to go fix this type of gasket, any number of corrective actions that people put in place, or do training, things like that. Then, what happens is that then they believe that they’re done. We always push to say, there should be a performance review a year later. You did a corrective action.
Now, the next process in place is to say, let’s do this performance review and see if the changes that we made were effective or not. If they’re not effective, then we have to go back to the drawing board because the problem still exists. It gives us the ability to circle back and having, again, those processes defined and laid out makes it easy so that people don’t miss those steps. Then, they understand, hey, I have to go and follow up with this performance to make sure that what we’re spending our time and energy on is actually effective.
That circles back to that next investigation in the field, and talking to those people. It gives them the stakeholder engagement piece from SMS to say, hey, we heard you. This is what we did. We followed up. It was or was not effective. What else do you have? What’s next?
Russel: Sheila, you mentioned Deming a little earlier. I’ve brought that up in some other podcasts. I probably have a passion for that, just because of my education and exposure to it early on. In the Deming approach, one of the things you do is you document in detail.
Deming, you mostly think about a manufacturing line, but you document in detail every single aspect of that manufacturing line, everything that’s occurring. Then, you look at, what is that particular node in the process creating in terms of final result? Then, you do your testing on the final result and you look back. I think about something like this.
I’m not a pipeline integrity person, so I’m reaching a little bit, but I think about a dig program. A dig is a pretty structured process. It’s pretty clear what you’re going to do. In addition to digging and exposing the pipe, you’re going to do a whole lot of data collection and analysis of that data. Then, you’re also going to correct something that caused you to do the dig in the first place.
Looking at that process and breaking it down to ‘what are they doing, what data they’re collecting, what value is that creating, and then how does that relate to what I’m able to establish as an MOP, and how that affects my downstream analysis when I’m thinking about running that segment of pipe.’ That, to me, gets a little bit clearer than when you just talk about process, task, and procedure. I can put my teeth into that. It’s something I can think about and I can get some clarity around it.
Sheila: Even in the example you brought up with a dig, we have heard stories where people have gone out, performed a dig, followed all their processes and their procedures, everything’s in place, but one thing people neglect is to review what you’ve already done.
The review, check, act — that whole piece. We’ve had stories where people have gone back and the ILI run shows an issue, a corrosion issue. They go and they plan to dig. Well, then they go to dig it all up, and there’s already a coding, already a sleeve on that pipe.
If they would have spent the time to review what was done — and it doesn’t take much time to review it all briefly — but if they would have reviewed what was done, they would have seen that that area, that pipe had already been addressed and not have to go back and spend the expense of going back, digging and going through to find that it was already being addressed.
Russel: That’s one of the big challenges in pipelining because it is a complex and technical business. There’s a lot of different specialties. The communication required between the different departments as these different activities are happening is a lot.
One of the things you can do with a good process is to define who are the people that are doing various parts of the process? That process will often jump across multiple departments…
Sheila: Yes, correct.
Russel: …and even up and down within those departments. There may be an engineer that I need to do a task, but there may be another process where I need a manager or someone else to analyze the task and do some quality control around the task. It’s a challenging thing.
What’s the possibility? What do people need to be thinking about as they’re moving towards pipeline safety management systems and they’re thinking about process? What’s the possibility?
Sheila: You get consistency. If you have a clear and defined process with the right ownership, then you can follow along and have consistency within those processes. If you look at from a safety management system, it really integrates all the systems processes into one complete framework. You may have multiple systems, but they’re all using the same processes. It’s, again, for consistency.
It enables you to have consistent processes around regions so that if you have a company that you have work being done in all these different states, having everybody doing the exact same process in a consistent fashion helps to build KPIs, comparisons, being able to measure between one state and another state who’s doing something better.
What are you doing differently that we can incorporate? As long as people are doing everything consistently, then you’re able to do that analysis and measure the maturity of your processes.
Russel: I think a lot of people when they hear you say that, Sheila, they would raise the issue about, “Well, different states may have different regulatory requirements. Different geographies may have different risks related to geology, geography, or population density and so forth.” How do you deal with that difference in the asset and yet still create consistency in the process?
Sheila: The process still has a foundational process. You can have five things that every state has to do no matter what. It’s a federal requirement or even just a company-required process. You can have a handful that are always consistent. One state may have more or less. Not necessarily less — one state may have more — but everybody’s going to have base foundational processes.
As far as different threats, you’re still reviewing it. The data output — the actual documentation that you’re capturing — that may be different from state to state, and we would expect that. The process on how to get that data, how to research that data, how to analyze that data — those steps and those tasks should all be the same from your objective of defining what’s my biggest threat. That should all be the same. Again, the results of your documentation may be different, but the processes should be the same.
Russel: That makes a lot of sense to me. If you think about a manufacturing model, again, going back to Deming, each line, you could go to three factories in different regions, and they would be identical once you walked into the factory. The way they ran their line would be identical.
They might have some differences in the way they do supply given where their supplies are located, whether, roads, or that kind of thing, but at a certain level, it becomes very consistent.
Sheila: Agree. When I was at DuPont — and I was at a plant — we ran, let’s say, two different types of widgets. The processes, for each of the lines, were the exact same, but the totally different product, different materials, different, everything.
The process on how to implement it, how to inspect, how to go through it, what person had, what roles, all of those pieces were clearly defined and consistent across the plant.
Russel: Interesting. Two completely different processes in terms of what was going on, but the management processes were identical?
Russel: That’s an interesting distinction. We haven’t ever talked about that, but the distinction between the actual process that’s occurring — like the chemical process and the chemical plant — versus the management process is an important distinction. The widget I’m building versus how I’m building the widget, or the widget I’m operating versus how I’m operating the widget. It seems so simple.
Why does everybody get so twisted up when they have this conversation and try to apply it?
Sheila: Like I said, it’s not defined. It’s not captured. It’s not written down. It’s all nebulous. It’s the way we’ve always done it, or the extreme — it’s not my job. You get this mix of people, and you have turnover now more than ever, historically. You have people coming in all the time, and the things are not clearly defined, even from a job description.
Your job description may tell you what you’re going to own in an area sense, but it doesn’t tell you how to do those things, what needs to be done, or what needs to be documented. A lot of those things get missed. In a lot of times, in today’s world, we’re not hiring somebody until that other person has already been gone for a while. [laughs] Even if he comes in, you really don’t know.
By having clearly-defined processes available, and a history of documentation, those people coming in are able to have that review, have that knowledge base at their fingertips, so that again, more consistency. People may come and go. There’s attrition. The knowledge that people have could all be captured in this documentation of previous processes that have already been completed.
Russel: One of the things that is true for me, at least, about Pipeline SMS is that one of the things that Pipeline SMS is doing is it’s standardizing what all pipelines should be doing, at least at a high level. Every pipeline has construction practices. Every pipeline has the “operating an MOP and integrity management” practices. Every pipeline has a control center. They have leak detection. They have leak response.
All of them have these basic practices and programs. Regardless of what product is in the pipeline — whether it’s a liquid or a gas, or whatever — they all have those basic practices. SMS begins to create a high-level, generic management framework.
Sheila: Like I was saying earlier, most management systems today are designed to achieve a single outcome, right quality, safety, compliance, whatever the case may be. Many companies then implement multiple management systems to accommodate each one of those single outcomes. What they don’t realize is that many of these systems contain the same processes.
Safety management system is a way to integrate all of those organization’s systems and processes into one framework to enable an organization to work as a single unit like a unified objective.
Russel: That tees up nicely the next question I have for you, is where do you think process management is headed in the pipeline world? What’s the future?
Sheila: I would say maybe some more like frameworks dashboarding. Being able to get KPIs around it; determining what the outcomes are supposed to be; being able to identify clearly corrective actions. Again, going back to the actual human element of the training — equipment, procedures, resources, scheduling, those seem to be what’s missed from a safety perspective that need to be addressed.
It seems like every issue that you find in any failure point always circles back to some human organizational bit.
Russel: Some human organizational gap, missing element, or something?
Sheila: The failure usually not so much in a process, so to speak. The failure is usually somewhere in the human interaction.
Russel: I certainly agree with that. I’ve said this on a number of podcasts, for us as an industry to get to another order of magnitude improvement in our safety performance, management systems and management systems all the way from the high-level pipeline safety management system all the way down into the details of what people are doing on a day-to-day basis is going to be, ultimately, what’s required.
Everybody I’ve said that to, they agree. It’s getting the products and the capabilities out there so that people can actually start doing those things — that’s the challenge.
Sheila: And to check it. You need to have an ability to go back and review what it is that you’re actually doing. To be able to measure maturity, track improvements, make sure your outcome is what you expect, that you have a predictable outcome. If I do A, B, C, I expect to get D.
Russel: Deming wrote about this a lot, about the fact that quality is everything. It’s not just “I put out 100 widgets and all 100 of them are good.” It’s everything through how I get to that final output. At that time, that was very radical thinking, very radical thinking. In fact, it got rejected in the U.S. initially.
Sheila: I think it is still a bit radical in some places. [laughs]
Russel: We tend to get focused on the thing that’s broken, the thing that needs fixed, or the thing that’s got to get built. We tend to get focused on those things. We tend to lose sight of the bigger picture of what we’re trying to do as a system and what’s the health of the system?
Sheila: When one of the things is putting out fires is not a process improvement.
Sheila: If you’ve already gotten to the end, you’re already broken, right?
Russel: I’ll tell another story. It summarizes that point quite well. When I was in the Air Force, my first assignment, the colonel I worked for, I’ll never forget this gentleman. He was awesome at teaching. He was an awesome manager and leader. I just learned a ton from him at a time when I was quite young.
I was in a meeting and there was this civil servant who was in charge of the fire department and the military NCO who was his second. The colonel was going around the room. He was asking, “What is the mission for your department?” He asked the civil servant in charge of the fire department for this large Air Force base, “What’s your mission?”
He said, “To put out fires.”
Then, he asked the NCO, “What’s your mission?”
He says, “To prevent fires.”
He says, “You’re the new chief of the fire department. You’re now the second,” and flipped them just because of that subtle, not very subtle, small, but very important difference in response. One talking about what’s the outcome I want? No fires.
I could have lots of fires and be the best in the world at putting them out in a hurry, but I’m not really a good fire department if that’s what my mission is. It’s a similar thing in pipelining. What’s our mission? It’s zero impact. Get the job done and zero impact.
Sheila: The goal is always for process quality management that the right job is done by the right person in the right way at the right time and in the right place.
Russel: Right, exactly.
Sheila: Then, you have the outcome that you’re looking for, which is zero events, zero safety issues, etc.
Russel: And accomplish the business objectives.
Russel: I think that’s the other thing that I don’t think we get yet as an industry, is the same approach can be used to optimize how we accomplish our business objectives. There’s actually value.
That’s one of the things we’re going to see in the future, is you’re going to see operations excellence, in other words, optimizing things for cost and performance, combined with safety management, which is no negative outcomes. Those two things need to work together. They actually will work together if it’s done correctly.
Sheila: Yeah, that’s correct.
Russel: How would you like to wrap up this conversation? What would you like to leave the listeners thinking about when it comes to process quality management?
Sheila: I would say don’t be afraid of it. It’s not additional work. It could actually be integrated into your current workflow and patterns. It’s an ability to make sure that things don’t get dropped, that the right people are doing the right things, that your whole system and your processes can be safer. Process management is not a bad word.
Russel: Exactly. That’s well said. That’s well said. Sheila, thanks for coming on the podcast. It was great to have you. I think we want to come bring you back and talk about some things around management systems, dashboarding, and risk management frameworks, as well.
Sheila: Oh, that would be great.
Russel: We’ll keep that in mind and we’ll continue to explore the conversation.
Sheila: Thanks, Russel. I appreciate it.
Russel: I hope you enjoyed this week’s episode of the Pipeliner’s Podcast and our conversation with Sheila. 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.
Russel: 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.
Transcription by CastingWords