This week’s Pipeliners Podcast episode features Gary White, former president and CEO of P.I. Confluence, discussing how to implement Pipeline SMS in a way that optimizes stakeholder feedback. This is episode three in a three-part series on the subject of Pipeline SMS.

In this episode, you will learn about the importance of starting with your objectives to implement Pipeline SMS, how to build an effective communication information exchange that leads to process improvements, the importance of defining processes as part of process management, and more topics that are valuable for effective implementation of Pipeline SMS.

Implementing 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.
  • P.I. 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).
• 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.
• 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.
  • HCA (High-Consequence Areas) are defined by PHMSA as a potential impact zone that contains 20 or more structures intended for human occupancy or an identified site. PHMSA identifies how pipeline operators must identify, prioritize, assess, evaluate, repair, and validate the integrity of gas transmission pipelines that could, in the event of a leak or failure, affect HCAs.
  • BAP (Baseline Assessment Plan) is the plan that a pipeline operator must develop to assess the integrity of gas transmission lines included in their Integrity Management Program.
    • In 2004, PHMSA issued the final rule, “Pipeline Safety: Pipeline Integrity Management in High Consequence Areas (Gas Transmission Pipelines).”
• Stakeholder Engagement is the process of reaching out to concerned or involved parties to communicate steps you are taking to mitigate risk, gather feedback from these parties, build communication loops to share lessons learned, and ensure emergency preparedness.
• CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
  • Shift Handover is defined as transferring responsibilities and tasks from one individual to another or a work team and it is one of the best-known types of safety-critical communication.
• 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.
• PMIQ (Process Management Intelligent Quotient) is the process of determining a start point of deciding on what decisions, communications, and issues should be captured in Pipeline SMS.

Implementing Pipeline SMS: Full Episode Transcript

Russel Treat:  Welcome to the Pipeliners Podcast, episode 181, 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.

[background music]

Announcer:  The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. And 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 to one listener each episode. This week, our winner is Ashley Baker with UGI. To learn how you can win this signature prize, stick around until the end of the episode.

This week, Gary White returns to talk about implementing Pipeline SMS to include stakeholder feedback — the Checking part of the Plan Do Check Act cycle. Gary, welcome back to the Pipeliners Podcast.

Gary White:  Hey, Russel. Thanks for having me.

Russel:  We’ve already done two episodes on SMS. We talked about what it is. We talked about how to do it, how do you apply it. Now I want to actually get into implementation and talk about what do you need to be successful to implement an SMS program.

Where the industry is, this is my opinion — I’d be interested in hearing your take — is they’re all starting to do something, and they’re all wondering what do they need in the way of systems to do this. You think that’s fair?

Gary:  Yeah. Let’s step up one level real quick for a second. I heard one of your podcast guests talk about something and said, “Well, yes, and where do you start?” He said, “Just start somewhere. Just do something.” The other gentleman said something a little bit different than that.

At the end of the day, you have to have a plan. You have to start by understanding what you have and don’t have, what’s your objectives. Right?

Russel:  Yeah. That’s absolutely right. What most people would do, and if you follow what API recommends, they’ve got this assessment process that’s fairly well documented, and have some good tools, and gives you the ability to do a current-state assessment around where you are related to SMS.

One of the things that is important is understanding that some of the elements in the SMS program are what people might call soft things like leadership, and stakeholder engagement, and management review. Those kinds of things are more soft, and others of them are more hard — they’re things you’re actually going to do like operational controls, risk management, and emergency preparedness.

From your perspective, do you start with the soft stuff, or do you start with the harder stuff?

Gary:  I think they’re already doing the hard stuff. They’ve been doing the hard stuff for years. The original transmission protocols had the A through N cycle, and it had HCA BAP threat risk and so forth. We called those the hard ones on the pipe.

They had quality assurance, management change, communications, recordkeeping, performance. These are soft ones. This is back in 2004. Like I said, one old operator told me, “We’re very good at planning and doing. We’re not so good at checking and acting.”

The soft elements of SMS are also the same soft elements that were in their transmission, gas transmission protocols, are the same things that industry struggles with conceptually, but the hard ones, they’ve been doing for years, and they will always do. The starting point is not starting soft or starting hard. It’s how do you apply the soft protocols or elements to the hard ones?

Russel:  That’s really well said, Gary. I’m sorry to interrupt you. I want you to talk about that a little bit more. What do you mean take the soft ones and apply them to the hard ones? That’s a really important concept.

Gary:  If you have stakeholder engagement, first of all, management change should set underneath everything you do. Every hard thing you do, you should have a way of managing change. That means what type of change, communicate the change — temporary or permanent? That is just everywhere. We have that.

We talk about stakeholder engagement. Stakeholder engagement is where you reach out to stakeholders and engage them to learn what you really have going on inside your culture, and you apply that to operations, to emergency response preparedness, and to every hard element. The management review — you have to apply that to the various different things you choose to review on a per hard element.

The soft things are the quality management bits that allow you to really achieve your Plan Do Check Act. At the end of the day, back when the transmission protocols came out, like I said, the soft ones, they were out there. Industry didn’t really get a firm grasp on them. They didn’t do much with them. The regulators didn’t either.

We went through many, many audits where we got through the hard stuff and stopped. It was good to go. It was an interesting exercise. Like I said, the SMS soft elements, the transmission protocol soft elements, they’re all the same. When I say integrate and apply them, I’m saying…

Russel:  The soft elements apply across the board to the hard elements. The hard elements tend to be a particular technical discipline.

Gary:  Something you do in your organizational bits, like scheduling and communications, recordkeeping, these are things you do. You have to apply them to each of the hard things. In risk, when do I communicate? Who do I communicate to? That should be defined. If it happens, I make this communication to this person.

Lessons learned, emergency preparedness. When do you tell somebody? When do you capture the lessons learned? Do you have a mechanism where you can post these lessons learned in such a fashion that your stakeholders can be notified about them and read them?

Maybe can you measure their understanding of what they read? So you can say, “I pushed out 100 lessons learned to 1,000 people. 82 percent read them. 75 percent of those guys actually understood the lesson.” Doesn’t mean they’re going to avoid it, but at least they’re aware. Some learn by doing. Some learn by failing. Some learn by somebody else failing. It can only help.

Russel:  The other thing that’s up for me in this conversation, too, is, when you talk about assessment, knowing where I’m at, the other thing is I think a lot of the assessments are oriented as “Am I doing the doing” — not “Am I doing the PDCA cycle for all the things I’m doing?”

Gary:  One pipeline company, many years ago — I’m going to exaggerate and say maybe 24 days after the law, regulation, or the standard came out — got certified with an international organization that they’re SMS certified. That’s fine. They’re doing all the dos. In fact, everybody is doing the dos right.

I hope you don’t mind this. I cringe when I hear people say “We’re already doing all that stuff. Just take credit for it.” Are you doing the Plan Do Check Act? Are you doing quality management against the things you’re doing? I’m not saying at the nth level. I’m saying just at a starting point, a very high level. Do we have any Plan Do Check Act requirements within emergency preparedness?

As you do this, then you can get better and better by doing them deeper and deeper in the weeds, like more granularity, but you have to have some concept that what I did, somebody looked at and used it for something.

Russel:  To that point, a different experience I had, there’s a pipeline operator I worked with in their control room. They had very evolved and mature procedures. They also had the highest level of change in those procedures of any organization I ever worked with.

The reason was they were constantly evaluating them and constantly updating them as they went through those. Every time they used them, if there was anything that came up that we ought to look at this, they would do a Plan Do Check Act and then make a change. Some of them were small. Some of them were pretty big but lots of change, and getting through the cycle quickly.

Gary:  Did they communicate those changes out to the appropriate parties and confirm that the appropriate parties understood the change?

Russel:  Yeah, they did all that. They did all that.

Gary:  Okay, well, that’s good.

Russel:  It was really very impressive to look at what they were doing, because not only were they making these changes, they were rolling those changes out. They’ve got systems in place to verify. This kind of thing gets tougher with shift workers, because you might not see them for two or three weeks, as they’re off rotation.

Gary:  Right, but another thing is, the final piece of that, Russel, in my view, is these changes are made, they’re made for a reason. Was the change effective? Whatever happened that made me make this change, did that thing stop happening or greatly reduce?

If you can measure that, otherwise, you’re just making changes, and you don’t know if they had any effect or not. That happens a lot. People make a lot of changes. They don’t circle back and see what it did or didn’t do.

Russel:  Yeah, no, that’s true. That’s probably the hardest part of the discipline.

Gary:  This goes back to mechanisms. If you have a mechanism in place, you can…We talked before about a situation where you had to put a drip on a pipeline, and the integrity and operations didn’t communicate all that well.

Integrity told the operations, “Hey, put a drip out there.” Well, did it get done? They don’t know. Integrity never knows. We had to build a process where the integrity guy would ask the operations guy, “Did it get done?”

If the answer was no, six months later, you get a reminder: “Ask them again.” Six months later: “Ask them again.” You might have 137 six-month processes that said, “I asked, and he said no.” Now, you’ve got some accountability. The guy never acknowledged making the change. You have to have a mechanism in place.

Russel:  I think that’s exactly right. Let’s unpack that a little bit. What are the elements of a system that you need? One of the things you want to do is you want your system, whatever that is, whatever software vendor or process you put in place to implement your system, there’s some pieces I think are critical.

They need to be implemented universally. One of the key ones is communications, and I would call it closed-loop communications, meaning the people that need the information get it, and the loop gets closed. They acknowledge that they got the information they needed.

I would assert that scheduling is critical, because I need to know, did it get scheduled? Did it get scheduled in the right time frame? Then, same thing, I need closed-loop scheduling. Did it get completed? Did it get completed in the timeframe?

Gary:  You can go one level higher than that. You’re 100 percent correct. One level higher would say, “The things I need to have are the ability to, what do I know, and what do I do? What are we doing, and what do we know?”

That’s your high-level objective for your mechanisms, to build something that tells me…

Russel:  That’s like starting point, and these other things I’m talking about are what are the other elements I need in order to facilitate the Plan Do Check Act.

Gary:  Yeah, if I’m doing something, what part do I communicate? Who do I communicate to? How do you close that loop? When I’m doing something else, how do I plan the schedule? How is the schedule shared? How is the schedule checked? How is the schedule executed?

There’s variance. How do you do variance? Those kinds of things that fit underneath there. Then asking your people, “Did you follow the schedule? Did you do certain things?” The softer side, or the people side of things, that’s what you know.

That’s asking people questions. Not questions that necessarily are trying to get anybody in trouble, just generally speaking, “How are we functioning as an organization?”

Russel:  Yeah, not seeking to blame, but seeking to understand.

Gary:  Exactly, exactly. That’s the highest level.

Russel:  That’s really important. The other thing that’s universal, too, is the recordkeeping. I use a term a lot called native compliance, meaning I should do my work, and the recordkeeping should just happen as I do my work.

In my world, the best example of that is shift handover, because that’s a required process in the Control Room Management Rule, and I need records that demonstrate I’m doing it and doing it by following a procedure. The best situation is if my system allows me to do a shift handover, and when I’m done with my shift handover, those records are just created by the system.

Gary:  Right.

Russel:  I think that’s universal to a lot of what we do, versus I’ve got to finish what I’m doing, then send an email, then grab the email, and save it over here.

Gary:  Yeah, it says, “Posts are created by the system. The system tracks that it happened.” You may have records that are like, “I logged my phone calls,” or, “I have the spreadsheet of some data, or some information somewhere.”

That’s developed during your work process, but the fact that you’re tracking that it happened, that system, the handover, shift change, it happened. When it happened, did you tell them what you saw? Did you tell them the alarms that are pending? Did you tell them these different statuses, right?

Russel:  Yeah, and then the question the auditors are beginning to ask these days is, “Show me.” I’ve got to be able to show that shift handover report.

Gary:  That’s what I’m saying. The mechanism tracks that it happened. It doesn’t generate information, per se, it tracks the fact that you did it and what you did. It doesn’t create data, it tracks.

Russel:  I would argue that, in the best situation, particularly when you get down to the working level, where I’m actually doing the work, is you’re actually capturing the record as you do the work.

When you get to the level of boots on the ground, a controller doing a shift handover, a field technician doing a safety valve check, the best thing is I do my check, I use my tool, and my tool creates the record that it happened, and the record, that is that demonstrates the compliance.

Gary:  Okay.

Russel:  That would be my assertion. Now, that’s a little bit maybe reaching, because when you start talking about this, that starts getting tough. When you start doing that, every single group that has a particular technical action they’ve got to do, their record’s different.

Gary:  Yeah, it’s a little simplistic, because you have — depending on what the group is, what they’re doing — I don’t know that you’d have one mechanism that does all these things, per se, but I think the overall approach of having mechanisms that feed into each other and support each other is reasonable.

Russel:  Yeah, right, I think that’s exactly right, too. It’s really an integration issue as much as it is a “one system that does it all.”

Gary:  I talked before about human integration. I talk about the idea that you do your job and develop a system to get records, then tell me. I take what you developed, and I’ve used it in my world, and I get something else accomplished.

I create something else, and then I tell your mother, and she says, “Okay, thank you for that,” and she does what she does. We have to have a system that makes sure that person A did something, gave it to B. B took it, did what he did, and gave it to C, and so on and so forth. It’s making sure the people side of things as opposed to the data necessarily connecting all through.

Russel:  To me, it’s a both/and. It’s not an either/or. You’ve got to have both. You’ve got to have the system connecting all the information, but you got to have the people working effectively as a team. It’s a both/and.

I think a lot of the breakdowns — this would be me asserting what I think the challenge is — but the nature of pipelining is it’s a lot of specialized, technical capabilities tending to exist in silos in a company. The challenge oftentimes is the communication between the silos.

Gary:  All the time, not oftentimes. All the time.

Russel:  Well, sometimes it’s communication within the silo.

Gary:  Oh, that, too. Right.

Russel:  It’s always communication, but it’s more often going between than within. Really, the challenge is that I have my context, then I pass what I do off to somebody else. And, they have their context, and it’s different. Normalizing all that’s a challenge.

Gary:  Part of the SMS is defining these handoffs, define these communications, defining what goes from A to B to C, and when. When do you tell somebody something? What does he do with that information? How do you document that that happened? That’s what the system is supposed to do.

Russel:  I’m going to co-opt this from you and say it’s mine. The whole podcast world will know that I’m doing this. But, it’s just between you and I. You used the term communication and information exchange as a critical element of a mature SMS solution.

That’s really what we’re talking about is that communication element — making sure it’s happening, that it’s happening timely, it’s complete, and it’s accurate. This is really critical because if that’s not happening, I can’t really do SMS well.

Gary:  The other half of that’s going to be process management — make sure that you’re consistently formalizing what you do, documenting it, and capturing it, and then triggering the proper response. Then, the other key communique, inside of there, you have a subset of communications inside there that are specific to what just happened.

The other communications are saying I’m going to communicate to my stakeholders something. Now I want them to participate in information exchange. Feedback, right?

Russel:  Right. Absolutely.

Gary:  If you have a process, by definition in my world, the process is an objective. What I want to do is I want to capture the decisions I made. I want to capture the records I generated. I want to capture the communications I made. I want to capture the problems I’ve found. These are all the important pieces that you put underneath the process objective.

You can add a number of other steps if you want to be procedural and say “did you brush your teeth?, wash your hair?, whatever.” At the end of the day, there’s key important things. These are decisions, communications, results, issues, and where do you go next. Do you carry on? Do you circle back? Do you stop?

That decision — that workflow — is based on the results of the decisions, and the communications, and the so on and so forth. That’s a core piece of a ball called process that has to be hooked, like an atom, hooked to many other balls, then it becomes a molecule, then it becomes a human being or something. That’s got to be done.

The challenge — I call it the Process Management Intelligent Quotient (PMIQ) — is what decisions? What communications? What issues. How much do I want to capture? You can’t go in there and capture everything all the time. You have to mature with this thing. You have to crawl, walk, run. You got to start with saying, basically, “What are the big points of this?”

Russel:  I actually think, Gary, that you make a really excellent point because one of the key things about checking, particularly as you have something in its infancy, is asking those questions. “Am I getting the right information? Am I asking the right questions?” More so than “Am I making the right decision?” The decision is an output of gathering the right information and asking the right questions.

If I’m gathering the right information and I’m asking the right questions, then I can start saying, “Well, is my process for doing the analysis effective?”

Gary:  Right.

Russel:  Then you can start asking, “Okay, well, am I getting the result I’m looking for, and is there a better way to get to this result, or is there a way to get to a better result?”

Gary:  Yeah, I’m not sure what the words were that I used in the last podcast, but something about do it over again and again and again and again and again.

Russel:  Yeah, we always have time to do it over. We don’t always have time to do it right.

Gary:  Well, but quality management is a continuous loop, and it goes on and on.

Russel:  You said a vicious cycle. That’s what you said.

Gary:  Yeah, a vicious cycle. It’s going to be that way, but it’s inward spiraling, ideally. Inward spiraling, so that you get tighter and tighter, right? It gets easier and easier, too, but you got to start off at the outside edges and say, “What questions do I ask? What do I know?”

Russel:  Yeah. [laughs] It’s much easier to do that around a specific task.

Gary:  Well, I’d say an area. I wouldn’t call it a task.

Russel:  What I’m saying is the more focused you get on the specifics, the easier it is to do.

Gary:  Oh, down the road, in the future state.

Russel:  Because there’s less ambiguity, and there’s less interconnectivity, it becomes easier to do. When you start getting at a very high level, and you’re asking the question, like, “Well, what is leadership and management controls?” If you’re asking that question, it’s a lot harder.

Gary:  Fortunately or unfortunately, that’s where you’ve got to start, right?

Russel:  Yeah. [laughs] That’s why it’s an inward spiral, because you keep circling and circling and circling and circling, and eventually, it tightens up.

Gary:  The reality is, let’s take, for example, a risk element. If you do Plan, do you plan risk high level? Do you plan risk? Do you execute risk? Do you validate, check the risk, and do you check the results of the risk? Do you check the execution of the risk, and do you take any action based on those two findings?

Real simple, right? It’s a, “Yes, we have a model. Yes, we run it.” I’ve got pipeline clients that run the model twice a year. They push the button another time. They don’t even look at the results. They just run the model so they can show they ran the model.

At the end of the day, the high level is, “Did you look at the results? Did you validate that you did it the right way, with the right data, and did you validate that the results? Did the results tell you something? Then, did you take action?” Start there.

Russel:  I think, coming back around to the idea of a system, is that you want to take as much of the administrative stuff off of the user as you can, so that, rather than me gathering records and storing records, I’m actually doing the analysis and determining next steps.

Gary:  The system, Russel, to me, this is one part of the system. The system actually has two parts. Like we said, communication, basic exchange, and also what you do (workflow). The workflow system is the fix to the Act to the Check of stakeholder engagement — the communication information exchange. Two of the elements there.

You have stakeholder engagement, you talk to the elements at all levels — boots on the ground, up and down. You ask a series of questions designed for that specific element and business unit to figure out what they look like.

Then, you take that analysis and spread it out. You say, “Okay, which one has the biggest gap, or the biggest lack of Plan Do Check Act?” Then, you take a process management solution, and you apply it to that one piece of that one element at the start.

You don’t say, “Okay, boys and girls, every element, starting tomorrow, you’ve got to process it.” You don’t do it that way. You do one, and you run it. Then you do another. That’s where leadership comes in. Leadership says, “Okay, let’s start with this one, and let’s watch it for a month or so,” or whatever, a year, whatever the time frame is.

Then, “Let’s take that information, and then now, roll it out to the next one. Let’s learn our lessons.”

Russel:  Whatever system you choose, you need to be able to start small.

Gary:  Well, you need to be able to focus it.

Russel:  Yeah, focus is a better word.

Gary:  Yeah, and then leadership tasks to support that.

Russel:  I’m aware of a couple of companies that are looking at large process management projects to implement SMS. I am skeptical because I’ve seen a lot of large projects fail.

Gary:  I went to the SMS conference up in Alberta, Calgary, or Edmonton. I don’t know what year it was, 2015, maybe, or ’16. Enbridge was up there presenting, and they had a slide. I still have it somewhere. 17 SMSes, and this big old picture had 17 business areas with the SMSes all dotted-line, dashed-line connected.

It was crazy, and they were trying to do it all at the same time. That was even crazier. I don’t think it ever came out of the hatch the right way. At the end of the day, you have to be able to crawl, walk, run. You want to change this thing, you don’t change it overnight.

You can do the stakeholder engagement across the entire company, and you should, because you do that every year over some frequency or measure your maturity. At least maturity of perceptions. Then, when you target an area for the solution, that’s when you apply process management.

When you apply process management inside your culture, you’re going to learn how your culture’s going to accept it, how they’re going to adapt to it. Then you go to the other piece of your culture and the other piece of your organization in the same culture, and you know less has learned already.

You maybe tweak a little bit somehow, but you’ve got to understand that it’s not hard, but it’s not fast. What’s that old adage, “Good, fast, and cheap, you can’t have all three,” right? This is not hard to do, but it’s not going to happen overnight.

The bottom line is stakeholder engagement tells you what you know, and then when you learn what you don’t know and what you’re not doing, then process management formalizes the execution of your processes — your dos.

Russel:  I think the way I want to wrap this up, Gary, if I might, is you talked about focus and focusing on one area, getting the processes defined in that one area, and then growing from there. I have always seen that being more effective than a massive project.

Gary:  No question about it. No question.

Russel:  Certainly, when you talk about the very large pipeline operators, they have resources and capabilities to do projects of that scale. Once you start getting down to the smaller operators, or even the mid-tier operators, they need things along the lines of “I can operationalize it quickly.” Part of what they’ve got to look for, I think, is the ability for a system to start small and grow quickly.

Gary:  Yeah, and wrapping up, one more thing I wanted to say is I’ve known the consultants and people that make a lot of money doing these SMS plans and their boilerplate documents. They line out these different things, and they say the right stuff with Plan Do Check Act, but they can’t implement it.

They have a growth curve where the curve goes up as they’re building this plan, get to the stop, and they start to execute, and then the engagement factor drops. It just drops like a rock.

All this time, all this money, and all this leadership buy-in to all this expenditures to build these documentation, documents — they can’t do it. They can’t make it work. You’ve got to have that tool or mechanism, system, whatever you want to call it to be the solution.

Russel:  That’s absolutely right. I think that’s absolutely right. That’s easy to say quickly on a podcast. It’s a much bigger challenge when you think about all the things a tool like this has to do.

Gary:  I think it’s easy. I think it’s easy.

Russel:  Well, maybe it is, and I’m just missing it.

Gary:  Again, like I said, it’s not hard, it’s just not fast. That’s the key to remember. It’s not going to be fast. It’s just going to be a slog.

Russel:  Well, that’s right. That’s right. Over time, you begin to build inertia, momentum, and make a difference. I think the implementation piece is so very critical. Having a good written program is of no real value if you don’t have good implementation. Having an okay program with good implementation is way more desirable.

Gary:  Let me tell you one last thing. When you do this system — this workflow process management system in whatever area you choose to start in — you best engage with the people using it. You’ve got to work with the people using it to develop this process, because again, they’re the ones that know what they do.

Russel:  Right. They’re the ones that are actually going to create the value for the organization, because they’re the one using it every day.

Gary:  Exactly, or make you realize the value of the investment in the tool.

Russel:  Hey, Gary, listen. Again, I appreciate it. Always a pleasure to visit, and this has been great.

Gary:  Send me a YETI.

Russel:  [laughs] Real simple, man. If you want a YETI, all you got to do is go to the website and apply to win. My sister-in-law had to go to the website and register to win to get a YETI.

Gary:  OK, I guess I don’t get a YETI. All right, thanks.

Russel:  [laughs] You don’t want to go the website and register to win, I can’t help that.

Gary:  [laughs] All right, Russel.

Russel:  All right, my friend.

Gary:  Thanks for having me.

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