This week’s Pipeliners Podcast episode features Jason DeWitt of ExxonMobil discussing his recent project consolidating verification and calibration measurements out in the field using Muddy Boots field operations software. Jason goes into detail why the plan was created and how challenging the standardization was to implement. 

In this episode, you will learn about the efforts behind the project, how it impacted consistent measurements by automatically calculating necessary information, and why efficiency is important.

Streamlining Field Measurement at ExxonMobil Using Muddy Boots Show Notes, Links, and Insider Terms

• Jason DeWitt is the Measurement Manager for XTO Energy (an ExxonMobil subsidiary). Connect with Jason on LinkedIn.
  • XTO Energy Inc. is an American energy company and subsidiary of ExxonMobil, acquired in 2010 and based out of Spring, Texas. It is involved with the production, processing, transportation, and development of oil and natural gas resources. The company specializes in developing shale gas via unconventional means like hydraulic fracturing and horizontal drilling.
  • ExxonMobil is an American multinational oil and gas corporation headquartered in Irving, Texas.
• Muddy Boots provides field operations software for pipeline operators to manage critical areas such as measurement, maintenance, work orders, site diagrams, shift logs, and well lists.
• EFM (Electronic Flow Measurement) has become a preferred method of natural gas measurement.
• MVS (Multi-Variable Sensor) These types of transmitters offer static pressure, differential pressure, and temperature measurement along with a flow calculator. It features local flow indicators to calculate accurate mass flow reading.
• DP (Differential Pressure) refers to the disparity in pressure between two points where both the reading and reference values may vary. It is determined by subtracting one pressure value from another.
• SP (Static Absolute Pressure) refers to the pressure exerted by a stationary fluid within a confined system. This pressure remains constant when the fluid is not in motion or experiences steady flow.
• API (American Petroleum Institute) is a national trade association that represents all aspects of America’s oil and natural gas industry.
  • API maintains a comprehensive Manual of Petroleum Measurement Standards (MPMS). The manual is an ongoing project that periodically releases new chapters and revisions of existing chapters.
  • API MPMS Chapter 21.1 (API 21.1 or 21.1) describes the minimum specifications for electronic gas measurement systems used in the measurement and recording of flow parameters of gaseous phase hydrocarbon and other related fluids for custody transfer applications using industry-recognized primary measurement devices.
  • Learn more about purchasing API standards.
• Automatic Tank Gauge (ATG) is an electronic device that measures levels of liquid in a tank. By monitoring the level of the liquid the ATG can perform leak tests of the underground tank and with some additional accessories can also monitor underground pressurized piping for leaks.

Streamlining Field Measurement at ExxonMobil Using Muddy Boots Full Episode Transcript

Russel Treat: Welcome to the “Pipeliners Podcast,” episode 331, 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 standard setting organization in 1919, API has developed more than 800 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 every episode. This week, our winner is Casey Miller with ONEOK. To learn how you can win this signature prize, stick around till the end of the episode.

This week, we talked to Jason DeWitt of ExxonMobil about their transition to a cloud solution for field measurement operations. Jason, welcome to the Pipeliner’s Podcast.

Jason DeWitt: Hey, Russel. Thank you for having me. I appreciate you doing this.

Russel: Before we dive in, why don’t you do this? Give us a little bit of your background. Tell us who you are, who you work for, what you do.

Jason: My name’s Jason DeWitt. I work for ExxonMobil. I sit as part of our legacy XTO business, which we’ve since renamed our Unconventional Upstream organization. I sit as our measurement manager that supports across our fields.

I’ve been with ExxonMobil for roughly, I guess, about 9 years now. Came in as an experienced hire. Got my teeth cut building measurement systems for some of the leading manufacturers across the US. Have since worked my way from downstream and refining over into our upstream operations.

Russel: This is an interesting conversation. This is a sidebar. We didn’t talk about this at all. I find it interesting that you’re not referring to yourself as XTO. It’s the ExxonMobil formerly known as XTO.

Jason: Exactly. We’ve got a lot of people, interesting enough, that still refer to themselves as legacy Mobil or legacy Exxon. There’s plenty of people around here that refer to themselves as legacy XTO Energy.

Russel: There’re certain names in our business that just seem to stick and don’t go away. XTO is certainly one of those names because they built such an awesome reputation. Anyways, enough of the sidebar.

I asked you to come on board and talk about your Muddy Boots project, primarily because of its size and scope and what y’all did there. Maybe you could start by telling us a little bit about just how big this project was, how many people, how many operations. What was the scope of the impact of this project? From there, we’ll ask you a little bit about why you did it and what were your goals.

Jason: Yeah, absolutely. If I can maybe take just a quick step back, I came over to the XTO part of the business, roughly, I guess, about four years ago on a special project to align the XTO business with our corporate measurement standard.

We were going through a consolidation. We had legacy downstream standards. We had legacy upstream standards. There was a big push, about five years ago, to go and consolidate these company measurement standards. That’s how I got tapped on the shoulder, I guess, to come over and work within the XTO business, was as a special project to go roll that standard out to XTO.

XTO, as you mentioned, has got a really big name here in the US. We grew by acquisition, which is really great, but it also means there’s a lot of preferences and localized decisions that are made that maybe don’t always agree with other operations.

For example, we might have one practice that’s adopted in our Permian business unit and a different practice that’s, not wrongly, but rightly adopted in a different business unit, just simply because of prejudice and preferences at the time.

Whenever I came over as part of that project to roll out that measurement standard, a lot of that has to do with field performance treatment, so verifications, calibrations, the like, of meters and measurement devices that the business has deemed critical.

As we were going through and surveying our equipment…We have, as you mentioned, a pretty big asset register here in the States. Then we also have an operation down in Argentina. It was pretty obvious to an outsider, because I had those cold eyes coming in, to look at the business and say…

“Hey, do we have a really good grasp on what we’re doing and the direction that we’re going from a measurement compliance standpoint? As the regulatory environment is changing, do we have a path to meeting some of those standards where they may exceed or be different than our internal company standards?”

It didn’t take long to recognize that our legacy system that we were working with, which also had grown by acquisition. We actually had 16 or 17, I forget, different servers that were set up to capture all this information into. That infrastructure was pretty big. In a similar fashion, that was managed individually, locally at those different business units.

We said, “There’s an opportunity here to go and look at the way we’re managing this and see if we can’t consolidate that into a common system and look for efficiencies in the way that we’re going about doing a lot of this verification and calibration work in the field.”

Russel: How many technicians were impacted by this transition?

Jason: At the time, of course, it changed from time to time, but roughly about 160 people were tagged with a full time measurement role. That’s composed of technicians in the field, foremen that are responsible for overseeing local programs, my team that consists of a couple engineers and some analysts that help support our back office work. Roughly 160 individuals.

Russel: I just want to give the listeners a little idea of scale. That’s big. Bottom line is that’s a big project. You laid out a little bit of the why and a little bit of the background. What were some of your key goals and objectives for the project?

Jason: As part of that, the implementation of that new consolidated company standard I mentioned, there are individualized frequencies and tolerances that are assigned for different types of measurement devices that are being used in different services of our operation.

You often hear, and this is some legacy terms, but class and purpose. Meter class and purpose. What are we using the measurement for and what really is the value of that measurement? Is it being used for some sort of fiscal transaction? Is it a facility balance point? Is it a regulatory reporting or fee type meter?

There’s all these categories of devices that we have in the field. A lot of them have differences in the performance treatment that we’re going to assign based on that business criticality you have. Whenever we did a survey in our existing system, the legacy system that we were using, we couldn’t tell the difference between, for example, an orifice EFM inside of our system and a tape and bob.

It was really challenging to go and look through that and say, “Hey, are we assigning these performance treatments correctly? How do we have, measurement assurance and certainty in our volumes that we’re producing in the field if we’re going to potentially not be able to close that gap on tying out meter to frequency on a requirement basis as instead of just letting individual fields go and willy nilly assign schedules to meet their business objective?”

Russel: There’s a lot bound up in what you just said there, Jason. Being a guy who started my career in measurement, I know about what you’re talking about here. This whole idea of even if I use the same meter element and the same EFM throughout all of my facilities, I still have different treatment.

If it’s a custody meter, an allocation meter, or a plant balance meter, all of that matters when you start looking at, “Well, what is the level of effort or expenditure from an O&M standpoint that I’m going to dedicate to running that meter?”

Then when you add all the other complexities about various EFM manufacturers, various instrument manufacturers, various meter types, and then you add, “Well, yeah, but this natural gas is dry and this natural gas is wet and this natural gas is wet,” when you start adding all those different factors, it gets highly complex really quickly.

Jason: It does. What a lot of people don’t appreciate that haven’t experienced what you’re speaking to in the field is that differences in operations, if you look at a pipeline system, you’ve got these big banks of meters. They may be 12 , 16 inch meters. They’re really, what I’ll call, a sexy system, a big, flashy system.

What we operate here in the US are just mountains and mountains of these little smaller meters. We’ve got tens of thousands of little three and four inch meters. People don’t appreciate whenever you go to calibrate a 12 inch meter versus a 3 inch meter, that workflow is exactly the same.

Those checks that you have to perform on that meter are exactly the same. That touch time is the same. Because we have such a larger volume of devices, our expenditure on time in a field and resources is quite a bit larger than even the balance of our ExxonMobil business partners.

Russel: Yeah, right. Exactly. When you have these extremely high meter accounts…I got a whole conversation going on in my head, as you’re bringing that up, and I’ll get spun out if I’m not careful.

You were going from a legacy system that was spread across 15 servers-ish all kind of operated and maintained and governed by the local field or the local area that’s operating the meters associated with that. You’re moving to an overall corporate approach to how you’re going to do your measurement.

The thing I’m hearing is there’s a very tight alignment or a lot of alignment between the system that you’re choosing to use and the standards that you are developing for how you’re actually going to do the work in the field. Am I hearing that correctly?

Jason: Yeah, absolutely. What we were able to do–of course, this was kind of a base criteria as we were evaluating platforms that we were going to move into–is we had to be able to differentiate in our system, even an orifice EFM from an orifice chart meter, because those two are going to have different types of treatments.

In the system that we’ve chosen, developed, in partnership with that provider is we were able to break out literally every different type of meter, the service that it’s being used in, what that purpose and business criticality is so that we can steward ourselves not against what we had previously defined, as you mentioned, individually governed a schedule that was established somewhere locally, that to be fair, for the most part was correct.

We pivot from there now, we understand the type of equipment. We understand the company and regulatory requirements, and expectations, and we can check ourselves directly against those expectations. We’ve got, basically, a living compliance and assessment that we can look at at any given point in time and see where we are on that scale of compliance with our company expectations.

Russel: Again, there’s a lot bound up in that. What were some of the challenges that came up as you were going through this project?

Jason: You mentioned one, even from different manufacturers. If we look at people’s preferences and prejudices based on history, basically, depending on where they worked and who their local suppliers are. In a similar fashion, the workflows that people use to go out and do this type of work in the field, maybe different from location to location.

For example, our Bakken assets may have a different kit and rig in their truck that they’re going to be using to calibrate a meter versus, maybe a summer environment or a warmer environment like an operation in Texas.

Those differences even in the sequence of events that are being followed for a calibration in the field was something we didn’t think was going to cause any upset but ended up being that we had to work through and get alignment between several different functions and folks to agree on a standard approach. Standardization is challenging, I’m sure you’ve seen that maybe in some of your…

[crosstalk]

Russel: Oh, yeah, even calibrating an orifice meter with a chart on it versus calibrating an orifice meter with an old set of instruments and an AFM versus calibrating orifice with a multivariable transmitter. Those are all three different things, right?

Jason: Yeah, absolutely.

Russel: Even though it’s all an orifice meter, it’s three different approaches to calibration. Then, you get into the equipment I’m going to use to do the calibration, and it’s all the things about all that.

Jason: It’s funny you say that, because specifically for that MVS (Multi-variable sensor), we have a form that’s for an MVS that has the pressure, the differential pressure, the static pressure and the temperature all rolled up in a form, but we also have a broken out, and so we have a DP form, an individual SP form, and an individual temperature forms just accommodate some of those preferences.

Russel: Yeah, yeah. That distinction. Sure. Just the diversity of what needed to occur was one of the challenges is what I hear you saying. What else was a challenge in the project?

Jason: As with anything, pivoting away from a legacy and comfortable system can be a challenge. There were lots of performance benefits for moving to a new platform that we could advertise, but you say something as part of a project tee up, and there’s probably a lot of people in the room going, and we’ll believe it when we see a captain type of thing.

Communicating across the field and saying, “Hey, we’re going to be moving and basically lifting and shifting our entire maintenance program from a measurement perspective out of one system into an entirely different system.” People get a little nervous around that. That was one.

Another might be some challenges around our IT environment. We were moving from what I would call an on prem dedicated server to manage this, where we have basically IT control and oversight around our entire system to where we arrived as a cloud based platform, so it’s outside of our environment, and we’re bringing information across an API back into our environment.

There was a pretty big bridge to cross with our IT organization to understand we’re moving something that people talk about the cash register of the business. We’re literally moving a lot of our SOX related information outside of the ExxonMobil environment into a cloud platform and then pulling that back into our system. There were some, I wouldn’t say needed diversity, but there were some challenges that we needed to go through in our conversations.

Russel: Being a guy that runs a software company and being familiar with what’s going on in the cyber environment and what the operators are doing with their agreements and their risk management programs to try to get a handle on all that. I imagine that that was some interesting conversations as you were teeing up the project and doing the advanced planning and making sure everything was going to meet ExxonMobil standards.

Jason: Yes, sir. it absolutely was. There were some compromises that needed to be made, but at the end of the day, we got our core functionality that we were needing, and we were able to overcome some of the concerns around both IDs, security, and even records retention.

Russel: How did that work? That actually is kind of an interesting question. One of the things that often comes up when an operator’s looking at a project of scale and particularly a project where records that they need as part of their audit file, if you will, are going to be in the cloud.

How did you all address that issue? How are you going to retain records where you retain records? What was your approach to that?

Jason: We needed to make a decision at some point about what we were going to deem to be a source record, so that’s what a lot of our internal controls tie back to is, what is the source of deep kind of pointed out? What are the sources of these volumes, and what is the basis by which those volumes were established?

Some of that ties to depending on the application of that meter ties to revenue recognition and some of our SOX control. Some of it ties to regulatory reporting. Interestingly enough, some of it ties to Indian reservation lands and some auditability that we have or we’re going to be subjected to around that.

To mitigate some of what I’ll say is our IT risk by having some of this information outside of our system, we came up with a methodology to basically in source or in house that record retention piece.

Our information passes through this external software. It’s pulled over an API into our internal data warehouse. That internal data warehouse is where we assign our records control and retention expectations.

Russel: Just restating it, making sure I understand what you’re saying, while the records are created in the cloud, they don’t stay in the cloud from a retention standpoint.

Jason: Right. They don’t only exist. We actually have a redundant system. I’m sure your audience is curious. Muddy Boots is the platform that we elected to go with. Muddy Boots actually has a record within their cloud environment. We also have a record within our internal environment, but we’ve deemed that internal record where we’re going to assign our records retention.

Russel: I think that’s actually a creative solution.

Jason: It was interesting. There were a couple other compromises we had to make also along the way, as far as the communication of data between our two systems. The way we established it was that we could pull information into our environment, but we couldn’t push information out.

I’m sure you’ve been broached with some of those conversations as part of your software conversations with oil and gas companies. That bidirectional communication of data seems to carry a higher risk weighting than just the consumption of data where we’re not providing information to an external environment, as an example of another compromise we had to make.

Russel: That actually spins me out into a whole nother conversation from a cybersecurity standpoint, about why is data in transit more risky than data in the cloud. That’s an interesting question, right?

Jason: It is.

Russel: I don’t know the answer to that, nor do I expect you to. It’s just another question that’s firing off in my brain.

Jason: Absolutely.

Russel: You talked about how you dealt with records retention. You talk about some of the challenges of a cloud solution. You also mentioned about the legacy. You’ve got a number of big organizations that have a long track record of doing this a particular way, and now you’re moving them to a new way of doing that work. What was your approach for dealing with that reality?

Jason: With a lot of these conversations, you have to be able to identify the value proposition for the user. Whenever you have that conversation with the field, understanding their pain points, understanding their hang ups with the existing system, where there’s opportunity space to go improve on that and offer additional value or efficiencies in the way that they do their work.

With the old system, we had a lot of back of the napkin calculation that was being used in order to input values into the forms, because the forms weren’t, what I’ll call, as intelligent as in our legacy system, where the new forms, whenever we put information into it, it understands all of that company requirements and expectations.

It actually gives us a pass fail flag. They can see that real time and understand if the test that they did was good, if they need to go do something else, whether they’re going to be in trouble with their foreman or their manager whenever they get back because they spent an entire day driving two hours into the field and didn’t get done what they needed to get done.

Being able to communicate that value proposition is key and really just putting yourself in that position and understanding what it is that they’re trying to achieve so that you can help them achieve their goals and what they’re trying to achieve in a better or more efficient fashion.

Russel: One of the things that the project did, or one of the benefits, was you built the required verification into the form so that you’re not relying on the technician to check the verification, but the verification is checked with the system that you use to perform the process.

Jason: Great example is API 21.1. API 21.1, which is a measurement standard, talks about electronic gas measurement. There are some criteria in there that uses both a function of the device that’s being checked, but also the reference equipment or the calibration equipment that’s being used to perform the check.

Each of those have some uncertainty bands that are just inherent to their performance. Based on that inherent performance uncertainty, whenever stacked up on top of each other, there’s a tolerance essentially that’s assigned for that check.

Instead of technicians having to go and pull up a data sheet or write it on the back of their calibration equipment so that they have it and they can use just a quick calculator type on their phone to work out what the tolerance is going to be, we built that into the system. We put all that information into the system and it performs those, for example, industry standard calculations on their behalf.

Russel: For anybody who doesn’t work in measurement and hadn’t had to do that out in the field, that is a non-trivial thing.

Knowing the nameplate accuracy of the transmitter and calibrating and the nameplate accuracy of the equipment I’m using and the last calibration of the equipment I’m using and its accuracy, and performing the math to make sure that I’m calibrating within the criteria set, which is another thing, that’s a non-trivial thing.

That takes time. To look all that up and run that calculation takes time. 10, 15 minutes, but you add that up 5, 10 times a day, it ends up being a substantial thing.

Jason: It’s funny you say that because whenever we were going through and building the logic for those forms, there were some really bright engineers, probably some of the brightest minds in this space that I work with here on the team. We were stumped for several days on how to go about implementing this.

Russel: I’ll bet.

Jason: We’re expecting people to do it in the field.

Russel: Exactly. If you can’t figure out how to do it in the office, what kind of results are you getting in the field? No reflection on the people doing the work, but it’s just a challenge.

One of the other things that we had talked about as we were preparing for this that I thought you guys did that was super creative is you all put together a war room when you stood up the new system, when you stood up Muddy Boots. Can you tell me a little bit about that? What were you trying to accomplish there and how did that work?

Jason: Just by happenstance, the way the project was rolled out or progressed, we ran out of a little bit of runway. We had a very short timeline. We didn’t have a whole lot of float in our schedule. It came down to that point of cutover.

We needed to cut over the entire business at once. We weren’t able to roll out Balkan, for example, and a week later, roll out Permian, a week later, roll out some of our Appalachia assets. We had to do everything all at once.

What we did in order to facilitate that is we actually got in a room, the entire team that I have here, and opened up a Zoom meeting. We created what we called a war room. It was literally 7:00 in the morning until whatever time we got off in the evening.

Technicians could call in as they were in the field, and because it is a cloud platform, we could fix things in the back-end. All they had to do was simply refresh on their side and they could see that fix in the field. We were ad hoc addressing issues that came up, understanding areas we needed to pivot, and building a punch list so that we could go address some of these things following that week.

We actually brought the developer from Muddy Boots into that war room with us, so we could part out and have little side conversations with technicians as they were having issues to work through.

It was actually pretty neat because, trial by fire, we all had to learn real quick the challenges that we were going to see in the field and maybe some of the things that we didn’t think about as we were going through the development of the rollout.

Russel: That’s just awesome. How long did you have the war room up before you didn’t need it anymore?

Jason: We gave people a week. It was a really hard cutover. We cut over in September of ’22. We did this thing where we hope to do it by the first of the month. There was a few things hanging out. We ended up doing it. We cut over on the 12th, which was a Monday that month and right in the middle of the month.

We pretty well absolved the business and said, “OK, for the month of September, we’re going to be half the time in our old system and half the time in our new system. Nobody’s going to know what’s going on.” That’s going to be our practice month. That’s going to be the month that we have to cut over.

That week of September 12th, we had the war room open the entire week. Then we had some small types of war rooms that popped up afterwards as people were moving different types of equipment into the system before the end of the month. Really it was just that one week and it was a crazy week.

Russel: 160 people and more than a dozen operating areas in a week. That’s pretty crazy.

Jason: It was pretty crazy.

Russel: Nobody would believe he could do that. If you put it into the plan that way, nobody would believe that that was impossible.

Jason: It was pretty crazy. Just to give you a little bit of an idea of scale, I looked this morning. We were in September of ’22 up to today, we’ve recorded over 158,000 activities in Muddy Boots. That boils down to about 120,000 activities recorded in that platform on an annual basis. It was no small feat.

Russel: About 10,000 activities a month. That’s a lot.

Jason: It’s a lot.

Russel: That’s a lot of stuff going on, for sure. What did you learn from all this? What are your takeaways now that you’ve kind of completed the project?

Jason: That’s a really good question. I would say some of my key takeaways from this is we were very fortunate to have a solution provider that understood the goal of success and recognized that our success was a mutual success for them.

I could say that as you’re going about some of these big projects, identifying a solution partner that has that appreciation for success, not, “Here’s a product, go squeeze this square peg into a round hole and try to figure that out.” We were lucky that way.

Another way was, like I mentioned before, I have some extremely talented people that I work with, I’m sure everybody would say, but surrounding yourself with people that are talented, have a shared vision, understand with ultimate clarity, where we’re going as an organization and what the end result needs to be. I think that’s been an ultimate success on our side.

Russel: I would like to underscore something you said, Jason, because I think it’s really important. I say this all the time, software never solves problem. People process, solve problems. Software becomes an enable. Software can destroy a project, but it can’t make a project successful. 

Jason: Totally agree with that. Yes, absolutely.

Russel: I think when you’re looking at a project like this, you’re looking at this type of thing, looking at not just what the tools are and what their capabilities are but the people behind them and their commitment to the industry and to the market and to the solutions.

Jason: I don’t know if you’ve experienced this as you’ve been around your career with some measurement folks. You mentioned this on a prior podcast I listen to, measurement folks because we are friends at our company and other companies, there’s a lot of elbow rubbing and a lot of interaction between third parties and different operations.

Integrity within that group of people, just because they’ve got the bug for measurement, just seems to be ultimately high. I can’t say that I’ve run genuinely run across a measurement technician in the field that didn’t have everybody’s interests at heart and looking after everybody as part of that transaction wanting to do a good job by way of documenting a lot of the work that they do, the good work that they do in the field.

Whenever you can communicate to them, the value proposition, share that as part of…We’re going to create some added clarity. We’re going to create an opportunity for you to better highlight the good work that you’re doing by way of implementing these digital systems that we roll up into, oftentimes, stewardship.

There’s value in that for them just being known and understanding that, “Hey, we’re the Guardsman. We’re looking after the house, or we’re looking after the city that you’re not we’re taking care of,” and being appreciated for that, because the measurement people often aren’t appreciated until the ox is in the ditch, and then it becomes ultimately important and…

Russel: We’re offensive lineman, Jason. We only get our name called when we screw up.

Jason: Exactly. Exactly.

Russel: Anyways, yeah, though, I think that’s interesting. Would you say that you accomplished the goals that you set out for the project?

Jason: We have. We have. There’s obviously room for improvement on any of these systems that rolled out. One of the other goals we didn’t talk about was that classing and purposing of meters that ends up being an annual activity for us, because the value of these meters change over time as facilities change and well rate change. There’s a continuous refreshing in that process.

We were able to integrate that into Muddy Boots as well, so we had that system that was our maintenance platform that had 16 or 17 different servers. We also had another system where we were managing this purpose and class review process in a different database.

We had other systems that we manage our volumes and integration, and we were able to further collapse two of those systems, so that was something we didn’t actually set out to do, and it just naturally happened. I think that was a really good success.

Russel: Anytime you reduce your system count, you’re winning.

Jason: Winning, yes, absolutely.

Russel: Yeah.

Jason: Absolutely. Now, there’s some other stuff that obviously we have on the docket to go do. We did a really good job whenever we rolled this out about bringing meters into the platform. The lion’s share of all of our volumes are moved by way of meters or pipeline, but we also sell a lot of product by way of tank and truck hauls.

There’s another piece of the puzzle that we’re working through right now. We’re planning another cut over real soon, where we’re going to bring tank instrumentation into the platform, so that we can have all the performance treatment and stewardship of those key measurement devices also included in Muddy Boots.

Russel: That is awesome. That’s awesome. One of the things that I think is really impressive about Muddy Boots is the variety of equipment that it already has predetermined activities for.

I think one of the things that XTO has done in your project, or ExxonMobil–Sorry, I’m having trouble making the transition too–One of the things that you guys have done is you’ve really figured out how to get beyond just getting the work done performing the calibrations and really made it about are we doing the right work in the right frequency to get the right result, and that requires a different way of thinking about doing these things.

Jason: Absolutely. There’s a lot of opportunities for efficiency there. If we think about just the size of what I’ll call the measurement army that ExxonMobil employs in this space, that’s a pretty hefty cost.

If you think about that number of people, just in people spend, were probably over $60 million a year and staffing people that didn’t count for equipment and trucks and cost of repairs and spare parts, all that stuff, just the employment of those individuals to go do this work. If we can find even small ways to be efficient, there’s economies of scale that can really be adopted here. We can find some real efficiencies in our business.

Russel: A little bit of efficiency gain for an organization of that size is still a pretty big financial number.

Jason: It can be.

Russel: Simple little things like fewer miles driven or fewer spares consumed and those kind of things, they make a big difference over the course of a year for an organization that size. No doubt.

Jason: Absolutely. Or even identifying equipment that doesn’t fail as frequently or doesn’t require calibration as often.

Russel: Here’s my final question for you. That is, knowing what you know now, what would you do differently on the project?

Jason: Oh boy. Whenever we first started this, it made a whole lot of sense to me to go work this and do this. To my fault, I probably tried to bulldog this a little bit harder than I needed to. That created some roadblocks for me internally and politically.

If I was to do it differently or do it better, I would probably bring a lot of those folks. IT is a great example. Bring IT to the table early on. Talk through some of this stuff so that they have a seat at the table. We can all build the ship as we’re sailing together. That would be probably something I would do different.

I also didn’t appreciate some of the small things. We’re talking about ATGs coming into, our automatic tank gauges coming into Muddy Boots here shortly. You would think that that would be a very, very simple form to create. It’s a check against your tape bob and whether it met a tolerance.

That’s a challenging activity. Whenever you think through some of these activities people do just by muscle memory and you really try to break it down in steps, it can be very challenging.

Russel: Oh man.

Jason: We tried to push, very aggressively, the development of some of this stuff and compress it to a short timeline. We slipped a couple times. To my own fault, I don’t think I was very realistic about the timing that we were going to cut over to this other. We did end up doing it all at once. It was fantastic once we did it, but it was quite a challenge at the moment.

Russel: I think there’s a lot of wisdom in those remarks, Jason. I’ve done a lot of projects like this, of scale. There’s a couple of things that I’ve learned, is the better job you do of orienting the full team that’s going to be impacted as to what you’re doing, why you’re doing it, and giving them an opportunity to put their feedback into the process, that’s super important upfront. It makes implementation go a lot better.

Likewise, anytime you think something is going to be simple, stop and reconsider it, because simple is just not the nature of our business. Normally what that means, particularly when a project manager says, “That’s going to be simple,” what that often means is, “I don’t understand what the real requirement is.”

Jason: That’s especially true for people like myself who are implants to a new organization, because if it was simple, it would have already been done. Anything worth still doing is going to be a challenge.

Russel: You guys are to be commended. This was not an incremental change. This was a transformational change. It was a transformational change at scale and with very hardcore deadlines. Those are the hardest projects to do. I don’t care what domain you’re talking about.

You laid out a lot of things you did. A couple of them are really noteworthy. You got really clear upfront as to why and the benefits you’re trying to get. You’re very deliberate about who you picked, not just what you picked. You got really clear that you were going to need to have focused intensity for the cutover to support the people impacted in the field.

I didn’t ask this question. I’ll tee this up as a statement. I’ll let you comment to it. I would suspect that when you were doing that cutover and you were working in that war room, there were some people that were shocked by how quickly you solved their problems.

Jason: It was. To be fair, some of the reason we did need to move over to a new system was there were a lot of pain points for the field. Fortunately for us, we had a suction for that change from the field.

It wasn’t so much we were hard selling the field on, “Hey, let’s go do something different because it’s different.” It was, “Hey, we’ve got some issues with our existing system. We need to go do something better.” We were able to deliver that for them.

There was a little bit of grace, I’ll say, that was offered from the field in that interim cutover period. People are excited about doing work. There were some heated conversations as part of that as is with any of these cutovers. Ultimately, everybody seems to be very happy with the result and the direction.

We’ve got 100 percent unanimous adoption of the system. In fact, we had a conversation the other day about potentially evaluating the use of this in some of our other business lines.

Russel: I really appreciate you taking the time to share this story. Thanks to you and thanks to ExxonMobil for allowing you to share this. These kinds of conversations are really a gift to the industry.

People need to know that these projects are possible. They need to know a little bit about how do you do them and pull them off. Really appreciate you coming on and appreciate you sharing your experience.

Jason: Russel, thank you so much for having me. I do appreciate what you’re doing here. I know this is a big suck on your time, and it does add a lot of value for the industry. I really appreciate all that you do.

Russel: Thank you so much. Look forward to having you back the next time you do a project like this.

Jason: Let’s talk in a couple of years.

Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Jason. Just a reminder, before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit PipelinePodcastNetwork.com/Win and enter yourself in the drawing.

If you’d like to support the podcast, please leave us a review. You can do that at Apple Podcast, Google Play, wherever you happen to listen. You can find instructions at PipelinePodcastNetwork.com.

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

Transcription by CastingWords