This week’s Pipeliners Podcast episode features Gary White, former president and CEO of P.I. Confluence, discussing the fundamentals of process management and pipeline SMS. This is episode one in a three-part series on this subject.

In this episode, you will learn how to define process management, the keys to a successful Plan Do Check Act cycle in pipeline operations, why “check” is often overlooked and why this is critical in process management and Pipeline SMS, how to build an effective continuous improvement cycle, the importance of stakeholder communications, and other key aspects.

Process Management and Pipeline SMS: Show Notes, Links, and Insider Terms

• Gary White is the retired former president and CEO of P.I. Confluence. Connect with Gary 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.
• The PRCI (Pipeline Research Council International) is the preeminent global collaborative research development organization of, by, and for the energy pipeline industry.
  • Listen to Pipeliners Podcast episode 54 with PRCI president Cliff Johnson on how the PRCI has developed a data hub to store information from across the pipeline industry.
• Integrity Management (Pipeline Integrity Management) is a systematic approach to operate and manage pipelines in a safe manner that complies with PHMSA regulations.
• DOT (Department of Transportation) is a cabinet-level agency of the federal government responsible for helping maintain and develop the nation’s transportation systems and infrastructure.
  • 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.
    • PHMSA published Advisory Bulletin ADB-2012-10 to inform owners and operators of gas and hazardous liquid pipelines that PHMSA has developed guidance on the elements and characteristics of a mature program evaluation process that uses meaningful metrics.
    • Jeff Weiss is the former Associate Administrator and Director of Program Development for PHMSA as part of the U.S. Office of Pipeline Safety.
• AGA (American Gas Association) represents companies delivering natural gas safely, reliably, and in an environmentally responsible way to help improve the quality of life for their customers every day. AGA’s mission is to provide clear value to its membership and serve as the indispensable, leading voice and facilitator on its behalf in promoting the safe, reliable, and efficient delivery of natural gas to homes and businesses across the nation.

Process Management and Pipeline SMS: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 175, sponsored by P.I. Confluence, providing software and implementation expertise for pipeline program governance applied to operations, Pipeline Safety Management, and compliance, using process management software to connect program to implementation. Find out more about P.I. Confluence at piconfluence.com.

[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 that appreciation, we give away a customized Yeti tumbler to one listener each week. This week, our winner is Elliot Ice with Marathon Petroleum. Congratulations, Elliot, your YETI is on its way. To learn how you can win this signature prize pack, stick around until the end of the episode.

This week, Gary White is joining us to talk about an introduction to process management and Pipeline SMS. Gary, welcome to the Pipeliners Podcast.

Gary White:  Thank you.

Russel:  Look, I am so glad to have you on. We’ve been talking for a while. I brought you on. We’re going to talk about SMS and really try to get into the nuts and bolts. I’ve done a number of podcasts on safety and pipeline safety management, but I think you bring an interesting perspective in terms of a real how-to.

Maybe I might start by asking you to do a little intro. Who are you? How’d you get into pipelining? A little bit about your background.

Gary:  Gary White. I was an engineer, late ’70s, working for Schlumberger, Halliburton, and various small, independent oil producers. Then in 2000, I think it was, I came to Houston and hooked up with PRCI, got involved in Direct Assessment (ECDA), and started working for an inspection firm.

Then I had the idea to build software based on the regulations after talking to the DOT research group and to a couple of the DOT gentlemen whom I saw in conference quite often.

Russel:  Tell me a little bit, if you would, about that. What was the nature of the idea? What did you see that was needed or missing in the market at that time?

Gary:  I was consulting for neighbors drilling in Houston, and a product we looked at from Adobe was a workflow product revolving around, I believe, it was expense accounts at the time, but it was workflow.

That intrigued me because I was always interested in how things went together. I’m a very logical, organized person, and so getting things ordered like that made sense to me.

Then when I first saw the regulations — proposed regulations for the Gas Rule in 2004 — I thought to myself that process management would be a definite advantage to an organization that had to comply with a prescriptive regulation.

Russel:  You’re talking about process management, and I’ve talked about this on other podcasts. You have asserted some alternate opinions to what I have said in the past, which I always think it’s interesting. How do you define process management? I think that’s something that’s not well-understood in the pipeline space.

Gary:  Process management is like who, what, when, where, and why. You manage those items so you can check:  Is the right person doing the right job at the right time, the right place, the right way? Process is, for us, a defined objective.

The objective is supported by the completion of a number of tasks. These tasks can be designed to check regulatory boxes, to make decisions, to control workflow, to capture supporting documentation, and these processes — when you go to workflow, you’re talking about one process that goes to the next process, which goes to the next process and so on. Or, if not completed properly, circles back to the previous process. You control the workflow.

Russel:  My background when I got my MBA was a quantitative MBA, and we did a lot of this kind of analysis, but it was all around manufacturing. I’m putting in bare metal, and I’m putting out cars, that kind of thing.

You were really looking in detail at all the steps and the sequences and so forth. One of the things to me that came out of that was that, how did you build a car before you had a process, before you knew how you were building a car? It’s a complex system, right?

Gary:  Yeah, I think people do, have always done, and will always do things. When you talk about process, you’re talking about more of a formalization of the concept. You’re documenting it. Actually, it’s, in the quality management terms, you want to plan what you’re going to do.

You want to do what you did. You want to check what you did, and you want to act on the results.  If it’s not proper results, if you will, you want to take action or adjust backwards to correct it going forward. Everybody plans and does, there’s a lot of “do” going on, but not a lot of connectivity.

Russel:  There’s a lot of do, do, do. There’s not a lot of plan, check, act.

Gary:  The thing we tell people is the idea of human integration. You have data integration, where one piece of software — somebody generates a piece of data that’s used somewhere else, and that generates information that’s used somewhere else, and so on, and so forth. Human integration is important. When Person A does something, who does he tell? When he does something, who does something next? If something doesn’t work, where does it go back to, and who do you tell? It’s human integration.

When you talk about pipeline integrity, there’s a lot of moving parts. To properly have an SMS, or to be safe, you have to have communications, workflow, handoffs, and feedback all along the way, from commissioning or design to commissioning all the way through to abandonment.

Russel:  Yeah, really, you have to do that for the entire life cycle of the pipe.

Gary:  Correct.

Russel:  Yeah, exactly. You mentioned quality management. What is quality management, and how is it different than process management?

Gary:  Quality management is, in general terms, the application of the plan, do, check, and act, or adjust, or improve, or correct cycle. It means plan what you’re going to do, execute your plans, your process, your procedures, check the results, and then take the proper action based on results.

Russel:  What is the result we’re looking for when you start talking about pipeline safety?

Gary:  Oh, gosh, well, the ultimate high-level result of pipeline safety, as everybody says, is zero incidents. You break that down a bit more granular, the result of a risk modeling. If I’m going to plan to calculate my risk, I’m going to execute my models and calculate my risk, I’m going to check those results and see if they are valid, if they make sense.

Based on what they tell me, if they’re correct and make sense, or don’t make sense or are incorrect, I may circle back and take action to correct my model. If they do make sense, I might take action to mitigate the situation that’s causing that higher risk evaluation.

Russel:  Right. When you say it like that, Gary, it’s one of those things where it seems pretty clear-cut and straightforward. I think a lot of people might say, “Well, we do that.”

Gary:  People do a lot of these parts. I think the biggest weakness in pipeline integrity is not the plan. There’s lots of plans. There’s lots of process, lots of procedures, lots of documentation, lots of doing, a lot of stuff going on.

I think that the check is where it starts to break down. I think most of the actions are reactionary. They’re reacting to something that happened. They’re based on lagging indicators. Something already happened, so they take an action, as opposed to a leading indicator, checking a result or checking some information, and having that drive an action in a premeditated sort of fashion.

Russel:  Yeah, what I would say being ahead of it, instead of behind it.

Gary:  Yeah, the pipeline industry has traditionally been behind it. There’s not that many. There’s been a few major incidents, obviously, but the regulations were all born from being behind it.

Russel:  Right. That’s right. That’s exactly right. Regulations come after the incident most of the time.

Gary:  Yeah, and the idea of the SMS is to try and get companies and people to get in front of it.

Russel:  Have you had experience with SMS, other than in the pipeline space?

Gary:  No, I’ve researched, obviously, and studied it, and seen plans and things in action in different industries, but no, not directly, no.

Russel:  I myself have. When I was in the Air Force at Tinker Air Force Base in Oklahoma City, they had a remanufacturing plant. They would take certain airframes, take them all the way apart, X-ray all the materials, put them all the way back together, and then fly them.

Basically, they’re flying the same airframe, but brand new. Take an existing aircraft and send it through a depot level repair, what they called that, and they flew a new aircraft. One of the last things they always did was a test flight.

We had an aircraft crash on takeoff, an A7. My desk was right next to the Air Force captain that was the senior accident investigator from the military side. There were a lot of other people that were civil servants and such, but it was really interesting to me, because what they ended up doing is they went through every single process in detail.

They eventually found out that there was a tech order, which is one of the specific tasks that has to happen, where they’re supposed to, that was missing related to engaging the locking mechanisms for the folding wings.

That had failed to be done, and when the aircraft went to take off, it got lift on the wing, the wing folded, and the aircraft crashed. Took them about three months, but the interesting thing about that is I don’t think they would have ever found the root cause if they didn’t have the process.

Because they found the root cause, and it was a process problem, a missing task, the fix was pretty straightforward.

Gary:  Right. Obviously, there’s no perfect solution. What we have found is, no matter how correct we think we get the processes designed and developed, there’s always feedback and circle back. There’s always room for improvement. There’s always something else that comes up.

If you’re doing leading indicators and doing process management, it doesn’t negate lag indicators. You’re always going to have things that happen that should force you or drive you backwards to make corrective action, right?

Russel:  Absolutely.

Gary:  A corrective action could be a leading indicator. A corrective action, which with leading indicators, it’s like with data. I have all this data. What is it telling me? What you should be asking is what do I need to know?

Russel:  Those are entirely different questions.

Gary:  Yeah, what do I need to know? Then I say, okay, what data will tell me what I need to know? Then I ask myself, do I have this data? Then I ask myself, if I have it, is there quality in that data? Can it be utilized? If I don’t have it, can I get it? If I can’t get it, then I have to adjust my parameters for how I use the data I have or can get.

Russel:  Exactly. I think that’s one of the things that gets complicated in integrity management. I know I’m a novice at best when it comes to integrity management. One of the things I do know is they deal with a huge amount of data.

It comes from multiple different data sources, and all the data impacts all the other data. It becomes quite complex quite quickly.

Gary:  I’ll tell you what, if a group of individuals have many disparate datasets — paper, plastic databases, different locations, decentralized, centralized — and they’re not checking, the lack of integrated data has minimal effect. However, when they start trying to check it, then it becomes a little bit more difficult, right?

Russel:  Well, right.

Gary:  That’s when you realize the severity of your data integration problem is only recognizable based on the level of your analysis and checking, right?

Russel:  Yeah. Oh, that is actually a deep concept right there, Gary. That’s a really deep concept, because if I can’t get to the data, I can’t do the check, what risk does that create?

Gary:  I’ve told people, and this may not be the proper thing to say, but I’ve told people, “If you’re not going to check, then don’t write anything down. Stop documenting what you’re doing.” If you’re not going to look at it, why bother? It’s just extra work.

Russel:  That’s the other thing that was really interesting to me in the work I did early in my career, in this vein, is that really, the important thing was to figure out what was the data that mattered? Just focus on getting that data, getting it every time, getting it consistently, and really looking at that data. Then determine what you need to add, if anything.

Gary:  Yeah, not just data, information. When you’re documenting a process, and you have to document 150 things, which ones are, five years from now, what’s going to be important? In a court of law, what’s going to be important?

For example, if a procedure says to wear blue pants, a red hat, and hand everybody on a certain street this pipeline safety information, well, five years from now, I want to know who got the information. I don’t really care if the guy had a blue hat and red pants or vice versa, right?

Russel:  Right, that’s right.

Gary:  You have process and procedures that are details on what you do, but they don’t all have to be documented.  Part of what I call process management IQ is designing or defining which tasks are critical, which ones track decisions, which ones track key information, which ones capture communications, and which ones manage the next workflow step, and so forth.

You don’t have to document everything you do. You just have to make sure you document the key things, or if situations require approval, where you circle the process to another level for approval before the workflow continues, you have to have that information handy that’s critical to that next level approving what you’ve done.

Russel:  Right, and yeah. This is one of those things where I’m listening to this conversation, my mind’s blowing up a little bit when I begin to think about just the complexity of what you’re saying here. Really, what you’re saying is to make sure that what you’re checking is what matters.

Gary:  And make sure you’re capturing what matters that needs to be checked.

Russel:  Exactly, yeah, two sides of the same coin. Get the right information and then check it. The other stuff, you don’t need.

Gary:  As you do that, once you get that in place, you should be continually trying to add to the mix. You can always think about different information that might tell me, “Once I know that X gives me Y, but I want to go Y and a half, what else can I get?” It’s not a set-in-stone situation. You should always be trying to improve your information collection, your data collection.

PHMSA put out that ADB years ago around 2013 about meaningful performance metrics, I think it was. That’s the key, meaningful. What does meaningful mean? Breaking down leading and lagging — industry has a difficult time with leading, because they don’t…Leading comes out of having a process. Did you do the right thing at the right time, the right person, the right place? Lagging is easy. I’ve got 75 of these, 24 of those, and something happened over there.

Russel:  Determining — figuring out what the leading indicators are, that’s the outcome of an analytical process, looking at the indicators you have.

Gary:  With plans and procedures, there’s detail work construction on what needs to be done. There’s a lot of experience behind that. It’s good experience and it’s good stuff.

It’s just a matter of formalizing at the point where you can then use it to carry on in a plan-do-check-act environment with workflow and process management.

Russel:  Yeah, exactly. One of the things I am remembering though about the analysis that I did is…It wouldn’t relate to pipelining, but is that you would often find as you mature the process that indicators revolve. The information; the meaning in the indicator becomes more dense as you understand it better. Then you begin to see the interrelationships between different indicators.

Gary:  What’s that saying? The more you know, the more you know you don’t know, or something like that?

Russel:  [laughs] Yeah, yes. There’s three domains of knowledge. There’s what I know, there’s what I don’t know, and there’s what I don’t know that I don’t know.

Gary:  Oh, that’s an old Sufi…

Russel:  The biggest opportunity exists in what I don’t know that I don’t know.

Gary:  There’s an old Sufi proverb about that, but I can’t remember the four parts of it. It ends up being, “He who knows not that he knows not is a fool, therefore, shun him.”

Russel:  [laughs] Yeah, there you go. The other thing we ought to talk about this, we talked a little bit about process management, a little bit about quality management. We should also talk about communication and information exchange. What is that?

Gary:  Before you jump there, can I go somewhere else for a second?

Russel:  Sure, please.

Gary:  In terms of the SMS, and quality management, the SMS, to me, it’s a systemic application for quality management to the various elements. If you take an SMS, and you have 10 elements, for example, and 8 of those, you say, “Well, I’m doing number 3, I’m doing number 4, I’m doing number 5.” You check the box. Doing those things is not what the SMS is about. It’s about “are you managing the planning, the doing, the checking, and the acting of those elements?” You can’t just say, “Well, yeah, I managed risk,” check the box.

As you talk about plan, do, check, and act — to segue to what you were going to say — that begets communications and information exchange.

Russel:  Yes, exactly. The other thing about that is who needs to get what information, and when do they need to get it?

Gary:  Obviously, there’s a line to be drawn between real-time and not real-time, if you will. There’s certain events that need to be managed in real-time, critical type situations, but for the most part, the key of communications and who needs to know results an/or decisions along the workflow.

People need to know before you carry on down the way. If you go through A, B, C, D, and get to J before you realize that B was done wrong, you’ve got a whole lot of backing up to do.

Russel:  Right. It’s interesting. I talk about this in the control room space, is that you know the best control rooms, because when you walk into them, they’re very calm. The processes seem very simple. The workflow is smooth, but it’s only that way because so much work’s been done on the processes and procedures in that control room to get there.

It’s the difference, if you think about a fire department, it’s the difference between firefighting and fire prevention. The best departments don’t have fires, but they’re very busy doing fire prevention. They still train for fires, but they don’t have fires.

Let’s talk a little bit more about communications and information exchange. How do you define that? I think that everybody has a notion about what that means, but in the context of safety management, what is communications and information exchange?

Gary:  Communications, if you go out, and you change a procedure, based on potentially a lagging indicator, if you will, and that procedure is changed and modified, don’t you think it’s a good idea to tell people? That’s communications.

If I find out that something we’re doing is being done wrong, and the procedure we’re using is incorrect, should I tell somebody? Information exchange is two-way. Information exchange is a little different in the sense that it’s where you ask somebody, and they tell you what they know.

Part of information exchange and communications, in my vision, is the stakeholder engagement. That’s what stakeholder engagement is. It’s communicating with your stakeholders and exchanging information with your stakeholders. Who better to know what’s going on than the guys with the boots on the ground?

Russel:  Absolutely.

Gary:  Back to the SMS scenario, if you’re applying plan, do, check, act, or adjust — whatever quality management principles to the elements of SMS — well, how do you know where to start? Well, stakeholder engagement will tell you the feedback from your people, whether you’re planning, doing, checking, acting, or doing it right, doing it wrong, what the issues are, so you know what to fix.

Of course, leadership has to sit on top of the whole darn thing, because leadership has to drive it. It can’t be an optional “Would you please take a look at this?” It’s got to be, “This is what we’re going to do,”

Russel:  Right. It actually has to become part of the culture. It’s got to become automatic.

Gary:  Cultures change over time. You can’t snap a finger and change a culture.

Russel:  No, absolutely not.

Gary:  Leadership could definitely support, force requirements that ultimately build the culture. You’re a military guy. You understand that, if it wasn’t for strong leadership saying, “Here’s how we roll,” that culture would never have been established.

Once it’s established, then newbies come in, and they’re immediately indoctrinated into, “Here’s what we do,” right?

Russel:  Yeah, they’re indoctrinated into it, but there’s also a whole lot of, “Here’s why we do it this way.” It’s not just what, it’s why. That’s just as important, but indoctrination is the right term, because it’s not the kind of thing that goes in easily.

Being a military guy and having gone to a military program and university, I can still quote what was ground into me. It went deeper than my memory. It went into my psyche.

Gary:  Even inside of organizations, you’re going to have cultures that are different. Every gas distribution company I’ve worked with, they’ve had some offices or areas that were really sharp, others that weren’t as good.

It’s just a typical cross-section of people, I suppose. The key is to think about why that is. It typically goes back to the leadership in the office. It’s not the executive level, but it’s still leadership at a certain level that dictates how they roll.

Russel:  The leadership that matters is the line leadership. It’s the people that are onboarding, training, and doing the OJT with the new people coming on. That’s the leadership that really matters, those guys closest to the pipe.

Gary:  If they have an opportunity to feed back up the ladder to the suits in the office about how to improve things, then that mechanism should be there. It should be listened to, and it should be checked and acted upon, right?

Russel:  When it’s acted upon, if that action gets clearly, timely, and effectively communicated back down, and it’s in alignment with what was communicated up, and there’s some support around that, it gets into what this communications and information exchange loop is really about.

Gary:  Here’s another part about information exchange. Let’s just say we have a new procedure change. We push it out, and we communicate. We tell everybody that it applies to, “Here’s the change.” Now, how do we measure that they understood the change?

How do we know they read the change? How do we analyze the effectiveness? Information exchange takes place where, when you disseminate a procedural change and communicate it to everybody, you have a mechanism someplace to allow you to ask them a couple of key questions.

Just short, two or three key questions about the change, and let them feed back. You can say, “I communicated this change to 87 percent of my people. 68 percent of those people gave me feedback. Of those, 32 percent actually understood the change.”

If those are your metrics, you might want to circle back and do it again. Information exchange is asking and gaining information back. Communication is almost like, communication is one-way. It can go either way, but it’s one person telling somebody else something.

Russel:  Right, and exchange is more a loop.

Gary:  The information exchange is actually, it’s two ways. I ask a question, I get an answer. I analyze the answer. Based on the analysis of the answers, I then go back and say, “Okay, well, this didn’t work. Let’s go fix something,” right?

Russel:  Yeah, it’s interesting, Gary, because in some of the leadership training I’ve done, one of the most valuable questions I ever learned to ask was, “What do you hear me saying?” One of the things about one-way communications, if you put 10 people in a room, and they all hear the same guy say the same thing, they all hear, in terms of what they internalize, something different.

Gary:  Or they take away something different, right.

Russel:  Exactly. One of the questions, and I will drive people crazy asking this question, “What do you hear me saying?” It’s the taking the temperature. “Okay, I said what I needed to say. Did you hear what I needed you to hear?”

Gary:  That’s why when you’re not in the same room together, obviously, and you’re doing part of SMS, you’re communicating things to people around your organization, all the way down to the boots on the ground level, you want to have a very simple way for them to provide feedback or response back that indicates that they got it.

At the end of the day, when you talk about maturity, you measure improvements. If I did this thing, and 84 percent got it, and 62 percent understood it, and the next time I did it, 95 percent got it, and 84 percent understood it, you’re showing improvements.

That goes back to an indication of your culture. Your culture gets these notifications, they take the time to read them. They actually are absorbing the information and letting you know that they understand. It’s a continuous improvement cycle, obviously, because you have to measure this stuff, or else you don’t know what’s going on.

Russel:  I think that’s so true. Certainly, in my experience, it’s very easy to operate in assumption. “I said it, they heard it, they said they understood it, but did they really?”

Gary:  I won’t name names, but I had a client who would stand up and say, “I want this thing done.” It’d be six engineers in front of them. Of the six engineers, four would back away, two would say, “okay,” and of the two that said, “okay,” one would go a little ways and stop. The one guy would go all the way, turn it in, and the guy would say, “That’s not what I wanted.”

Russel:  [laughs] Yeah. That’s a leadership problem, because it’s really leadership’s role to have the communication received the way it needs to be received to have the impact caused that you’re looking to have caused.

Gary:  Yeah, it’s communication. Agreed, 100 percent.

Russel:  That’s really what you’re driving at, is some people might simplify that and say, “You need effective communications,” but what you’re really getting to is the mechanism.

Gary:  Yeah, it goes both ways with the takeaway. If I say something, and I take away that you heard it this way, and you take away a different way, then we’re not on the same page.

Russel:  Right. That’s exactly right. That happens. That’s just the nature of being human beings. I’ve had issues like this, particularly when you start dealing with things that are highly technical, or you’re using jargon.

One of the things I do is a SCADA fundamentals training. The most important part of that is just definitions, because we all use the same words to mean different things.

Gary:  That reminds me of definitions of process and procedure, and how PHMSA’s mixed those two up for years and years and years. I’ve got thousands of hours of consulting, basically being the guy who took what leadership said and paraphrased it to an understandable fashion, and shared it with the guys who had to do the work, and made sure they understood it. Being in that role.

Russel:  Right, yeah. I want to ask a wind-up question here in a second, but I want to let the listeners know that Gary and I are going to be doing a three-part episode. This is the first bit. We’re going to do another episode more on how you actually apply SMS to the various elements, how you apply the elements into the various disciplines, like transmission lines, distribution lines, and so forth.

Then we’re also going to do an episode on implementation and specifics of what are the things you need and the tools to do this and do it well. I think there’s a lot of people looking at this right now and I’m trying to put something together here that’ll be of value.

I think, Gary, the last question I have for you is what do you think people miss about SMS about what it’s about?

Gary:  First of all, SMS is not a regulatory requirement. It’s an industry best practice. The only time PHMSA’s used SMS in regulatory speak is as a corrective action order. They required somebody to do an SMS.

A lot of the mindset around regulations is “check the box.” I have had many conversations with Jeff Weiss when he was in charge of PHMSA, talking about breaking that mindset of check the box. Do the right thing. Take care of business.

If you take care of business and do the right thing, compliance will…You had this conversation with one of your guests recently. Compliance will take care of itself, right?

Russel:  Absolutely.

Gary:  The SMS not being regulatory, it’s a do-the-right-thing document system. You have to want to do the right thing. That involves the whole quality management, systemic quality management infusion, if you will. Are we planning?

It’s funny, because you do a plan, you check your plan. You do a do, you check your do. You check, you act. It’s all mixed up together, but at the end of the day, it’s a continuous improvement cycle, and it has to be set up to apply to all the key functions of your business that in any way, shape, or form might have an input to safety.

A bad design, bad commissioning, a bad construction, there’s all kinds of things along the way that could ultimately bite you down the road.

Russel:  I think the other thing that people should understand is that, by and large, the industry has bought into the idea of Pipeline SMS. We are very much, even though there’s a lot of effort going into it, we’re very much in the infancy of this implementation.

It’s the kind of thing that it’s going to take a long time to really get where we want to go. It’s going to change a lot of the way that we work, I think.

Gary:  I saw the AGA announce that they’re going to require or request all their members have an SMS, and everybody’s talking to SMS. It’s a lot of verbal discussion about SMS. That’s all well and fine. At the end of the day, you say it’s going to be hard.

When people say we’re already doing most of the stuff, that’s true, but people have a hard time getting their arms around is the quality management component. Once you get the…

Russel:  It’s the check part that I think…I think you nailed it right at the beginning of this conversation. It’s the check part that makes it difficult.

Gary:  We’re going to land back on, at the end of the day, like you mentioned before about the toolsets. You have to have mechanisms in place that allow you to do the check in a timely fashion so that you can put the brakes on and turn it around before you go too far down the road.

What was that deal where somebody put the wrong shrink sleeves on a pipeline, and 30, 40 miles later or whatever, they had problems, or the pipeline blew up after the six months of service, or whatever the case may be? There’s always enough time to do it over again, but never enough time to do it right the first time.

Russel:  I think football, particularly football played at a high level, is a great example of this whole plan, do, check, act kind of thing because every single play is a process. In the midst of every play, there’s people doing things. They have a plan because they call a play. They execute the play.

Immediately after the play is run, there’s people breaking down the blocking. They’re breaking down what the defense did. Then coaches are making adjustments. As soon as the players come off on the sideline, they’re coaching them up and saying, “This is what you need to change about your technique,” or, “This is what we’re going to change about the play-calling…”

Gary: In-game adjustments, right?

Russel:  Yeah, the quarterback’s doing that in the midst of the play calling audibles. The coaches on the sidelines are doing it as the offense comes off as defense comes off. Then they’re doing it again at halftime.

Gary:  They’ve got iPads now, or some kind of Microsoft Surface, or whatever. They have computers to sit on the sidelines with computers.

Russel:  What makes all that work is they have a game plan, and every player knows their position and their assignments. They have something to adjust from. You got to have something to adjust from, and then you got to wait to check.

The other thing, I don’t think people that are not real students of the game really understand what all the coaches are doing. When you look at top levels of college in pro football, there’s coaches evaluating every player on every play and logging it.

Gary:  One of the key things — you just said it. It’s a good point, but back to pipelining is that you have to understand “what are we currently doing?” That gives you your baseline to adjust from, right?

Russel:  Absolutely.

Gary:  Many areas, they don’t know what they’re currently doing, or it’s not being done consistently, or it’s not being done according to procedure. There’s all kinds of variations on the theme there. But, the other day, you have to have that baseline. That’s back to stakeholder engagement.

That’s how you find out. Your stakeholder engagement — find out what we’re actually doing. We can compare it to what we think we should be doing that we have to change, right?

Russel:  [laughs] Exactly. Again, you just said a mouthful. Listen, I think this is a great place to wrap up the first one. We’ll do that, and we’re going to pick it up on the application of SMS in the next episode. Gary, thanks for coming on. I’ll look forward to getting back with you.

Gary:  Thanks, Russel.

Russel:  I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Gary. 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’d like to support the podcast, please leave us a review on Apple Podcast, Google Play, or on your smart device podcast app. You could find instructions at pipelinepodcastnetwork.com.

[music]

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