This week’s Pipeliners Podcast episode features first-time guest David Miller of API providing listeners with insight on the API standards development process to promote safety throughout the oil and gas industry.

In this episode, you will learn about the process that goes into approving a standard, how many standards are crafted each year, the audit and review process to maintain the integrity of standards, and the role of PHMSA incorporating these standards by reference in rulemaking that affects pipeline operators.

You will also learn about upcoming standards in the works to address new technology, the critical role of industry subject matter experts participating in the development of new standards, and more interesting information about the API standards process.

API Standards Process: Show Notes, Links, and Insider Terms

• David Miller is the Director of Standards with API. Connect with David on LinkedIn.
• API (American Petroleum Institute) represents all segments of America’s natural gas and oil industry. API has developed more than 700 standards to enhance operational and environmental safety, efficiency, and sustainability.
  • The API Weekly Statistical Bulletin (WSB) has been published since 1929. The WSB reports total U.S. and regional crude inventories and data related to refinery operations.
  • All Open Ballots is the API Balloting System that allows for public voting and public comments on recommendations published by API committee groups.
• Additive manufacturing (or 3D printing) is the industrial process of adding material to production to create lighter and stronger final products. The advanced use of technology enables manufacturers to achieve this objective.
• ANSI (American National Standards Institute) oversees the development of consensus standards for products, services, processes, systems, and personnel in the U.S.
  • American National Standards (ANS) are a collection of standards published by ANSI and then reviewed over time to ensure that each standard is still valid.
• NIST (National Institute of Standards and Technology) is a physical sciences laboratory and a non-regulatory agency of the United States Department of Commerce. Its mission is to promote innovation and industrial competitiveness.
• 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.
  • Pipeline Regulatory Committees review proposed PHMSA rulemaking to ensure the technical feasibility, reasonableness, cost-effectiveness, and practicability of each proposal.
• The Aliso Canyon gas leak in 2015 was the result of natural gas escaping from a well within the Aliso Canyon’s underground storage facility in the Santa Susana Mountains near Porter Ranch, Los Angeles. The facility was operated by the Southern California Gas Company, who discovered the leak after residents complained of symptoms associated with natural gas exposure. Following the incident, Congress directed PHMSA to establish new safety standards for underground gas storage facilities.
• API Standard 1170 (Design and Operation of Solution-mined Salt Caverns Used for Natural Gas Storage) is a recommended practice for salt cavern facilities used for natural gas storage service. The RP, issued in July 2015, covers facility geomechanical assessments, cavern well design and drilling, solution mining techniques, and operations, including monitoring and maintenance practices.
• API Standard 1171 (Functional Integrity of Natural Gas Storage in Depleted Hydrocarbon Reservoirs and Aquifer Reservoirs) is a recommended practice that applies to natural gas storage in depleted oil and gas reservoirs and aquifer reservoirs. The RP, issued in September 2015, focuses on storage well, reservoir, and fluid management for functional integrity in design, construction, operation, monitoring, maintenance, and documentation practices.
  • The Underground Natural Gas Storage Facility Rule published by PHMSA incorporates by reference API 1170 and 1171.
• National Technology Transfer and Advancement Act (NTTAA) was signed into law in March 1996 to bring technology and industrial innovation to the marketplace, help U.S. business speed the development of new products and processes, and foster commercialization of technology and industrial innovation.
  • Additional policy guidance relating to the implementation of NTTAA was included in Revised OMB Circular A-119 published in January 2016.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote locations.
• IoT (Internet of Things) is a system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.
• Carbon Capture (CC) is the process of capturing waste carbon dioxide, transporting it to a storage site, and depositing it at a separate location where it will not enter the atmosphere.

API Standards Process: Full Episode Transcript

Russel Treat: Welcome to the Pipeliners Podcast, episode 162, sponsored by the American Petroleum Institute, driving safety, environmental protection, and sustainability across the natural gas and oil industry through world-class standards and safety programs. Since its formation as a standards-setting organization in 1919, API has developed more than 700 standards to enhance industry operations worldwide. Find out more about API at api.org.

[background music]

Announcer: The Pipeliners Podcast where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now your host, Russel Treat.

Russel: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time. To show that appreciation we’re giving away a customized YETI tumbler to one listener each episode. This week, our winner is Frank Onesto with Burns & McDonnell. Congratulations, Frank. Your YETI is on its way. To learn how you can win this signature prize pack, stick around to the end of the episode.

This week, David Miller, Director of Standards with API, joins us to talk about the API standards development process. David, welcome to the Pipeliners Podcast.

David Miller: Thank you very much. I’m looking forward to the conversation.

Russel: Likewise. I’m really excited to have API involved with the podcast. I’ve been having conversations with you guys for a while about getting you to come on and talk about standards, and I’m really excited about this. I think it’s going to be awesome.

David: I’m looking forward to it. Standards is one of our foundational programs. As a director of the standards program, you’re probably not surprised I never tire of talking about standards.

Russel: [laughs] That’s a good thing because the API’s got a lot going on in that domain. Maybe, David, before we dive in too deep, could you give yourself a little bit of an introduction and tell the listeners a little bit about your background?

David: I’d be happy to do that. I’m a graduate of the University of Utah. I lived in Texas for most of my life growing up, but we moved out West when I was still in high school. I went to college out there; graduated with a degree in civil engineering and tried to find a job as soon as I could that would get me back to Texas.

It turned out that I found a job in the oil industry, working for a wireline company out of Fort Worth, Texas. I moved back and did that for a while, worked in the oil patch, as we call it. Then went back into engineering in Houston and Dallas and ultimately joined API in 1985. Moved up to D.C. in 1990, and I’ve been there now — hard to believe — 35 years. I’m involved in API’s technical programs, primarily in the standardization area.

Russel: Well, time certainly flies when you’re having fun.

David: It does.

Russel: Tell us a little bit about the history of API and how API started. What is its background? How did API get started with standards?

Russel: Sure, happy to do that. API has been around a little over 100 years. In fact, we celebrated our centennial last year. We were formed in 1919 really as an organization to work on three foundational programs.

The first foundational program that the institute was formed to work on was standards and standardization. There was no common industry standards out there. If you were drilling a well and you, say, needed some additional drill pipe. The manufacturer you were working with wasn’t available or couldn’t provide that to you and you went to a different manufacturer, sometimes the threads wouldn’t match up. Obviously, that’s not a good thing from a safety and interchangeability standpoint. One of the foundational programs for the institute was technical standards. That’s the group that I lead now.

The second program that we took on that we’re still doing was statistics. There was no industry wide-accepted statistics. We now publish the weekly statistical bulletin. That’s been published for many, many years, and it is the most widely followed statistical bulletin that talks about industry statistics, production, refinery runs, things of that nature. We’re continuing to do that.

The last program that we started, and it’s really a technical program when you think about it, was working with the federal, state, and local governments on industry taxation issues, because there was just a wide variety of how industry was taxed, and there was a need to work with the regulators directly.

If you think about it, our foundation really ties into both technical work and industry advocacy work, if you will, from the standpoint of the taxation side. That’s how the institute got stood up all those years ago.

Russel: Interesting. David, what is the scope of standards that API addresses? I don’t think that’s well understood. I mean, this is obviously the Pipeliners Podcast, but API is much broader than that.

David: As I said, we were formed in 1919 with standards being one of those foundational programs. We published our first standard a few years after that in 1924. It was on — as I mentioned earlier — drill threads being an important issue for standard, for safety, and for interchangeability.

Since then, we’ve grown our standards program from that first standard to over 700 standards that cover all of the segments of the supply chain for oil and natural gas. We’re the only standards developing organization that is focused solely on oil and natural gas as an industry.

Because of that, we develop standards, of course, in exploration and production. We develop standards in pipeline and in measurement. We produce standards on how you get it out of the ground, how you get it from where you need it to be to somewhere else. We produce standards on refinery processes, and of course, marketing and getting the end product to the end user. We have a little over, as I said, 700 standards that cover all the different aspects of the oil and natural gas industry.

Russel: This is a question I think is interesting. 700 standards, and you’re addressing everything basically from the reservoir to the end user?

David: That’s correct.

Russel: How many gaps do you think you have?

David: This is something that we work with our members all the time. We have a series of governance committees that are made up of the top engineering managers within each of the disciplines that support our standards programs. We look at the overall standard suite twice a year and really talk about well, “Where are the gaps? Where are the areas that we need to be developing new standards in?”

For example, one of the newer standards that we’re working on in the area for exploration and production right now is on additive manufacturing, or what we used to call 3D printing. Additive manufacturing is a new technology that I think has a tremendous opportunity to be a game-changer for our industry.

I know that’s a tired phrase, but if you think about it, a lot of the places that we operate both here in the U.S. and around the world are going to be remote. It’s going to be difficult at times to get replacement parts there. It’s going to be difficult if you have equipment that’s been installed and that’s been there a long time.

The ability to create a series of standards for additive manufacturing where you can create those parts as you need them is really a key, but that’s in exploration and production.

When I think about some of the new areas that we’re working on in pipeline in particular — since of course this is the Pipeliners Podcast, so we should focus on that — we’ve just started a new project, actually just in the last few weeks, on a new standard on public engagement for pipelines.

When you think about it, there’s a full lifecycle of pipelines. When you initially decide where the pipeline is going to go, you have to work with the permitting side. You have to work with the communities. You have to work with a lot of different stakeholders. Of course, that’s extremely critical these days.

We’re developing a standard, working with a very balanced committee of individuals, to say what are some of those best practices that people should be following as you’re looking to put these pipelines through these communities?

Russel: It’s interesting. This is podcast #162, and I’m always amazed at how little I know about pipelining.

[laughter]

Russel: The domain of what I don’t know just seems to be ever-growing. I think the interesting question about standards is technology evolves, the way we do the business evolves, and the standards have to evolve along with that.

You say 700. I would assume that’s the active. How many standards have been legacied or basically said, “No longer of use?”

David: We have a requirement. We’ll get into this at some point, I’m sure, when we talk today about our standards review cycle. All of our standards in accordance with our accredited process have to be revised, reaffirmed, or withdrawn every five years. There’s literally thousands of standards over the years that we’ve replaced with newer additions or newer technologies.

I think if I go back into some of the older standards when I’ve done a bit of research on some of these topics, I’ll find standards that we developed years ago on storage tanks made of wood, which told you how to design and properly install a tank made of wood. At the time, that was a practice that was fairly commonly used in the more remote oil fields.

So probably literally thousands. I’ve never done a hard count. That’d be an interesting project. Maybe I should look into that.

Russel: I do think it’s interesting to realize that not only are you creating new standards and revising standards you have, but you’re also deliberately saying, “You know what? We don’t need to maintain this standard anymore.” After 100 years, that’s got to be a pretty big number.

David: Yeah. We do take a very hard look at all of the standards as they come up for the renewal cycle and determine what the appropriate next steps are with them, because we recognize as valuable as they are, of course, they are a burden for industry to maintain. They are a burden for the folks to keep active.

We always take a hard look at those and make sure that our suite is really meeting industry’s needs and serving society in a way that provides that safe, reliable, and sustainable energy that, quite frankly, the economy runs on.

Russel: Yeah, exactly. How would you state the core mission of the API as it relates to standards?

David: It’s really easy. The API mission is to promote safety across the industry globally and to influence public policy in support of a strong, viable U.S. oil and natural gas industry. When you really focus on the first few words of that mission statement, promoting safety across the industry globally, you really can’t do that without strong technical standards.

You really can’t have safe operations if you don’t have standards by which everybody can understand what the requirements are for the equipment, for interchangeability, for operations, for things of that nature. It reminds me of a comment I was thinking about the other day.

My father-in-law was a landman. For those who don’t know in the exploration production field, that’s the individual that puts together the various leases on the sites, and works with the landowners, and works with the regulators; everything that goes into putting an oil and gas lease.

When I told him I was joining API, he said the first time he ran into API was when he had gone out to a well site, he was checking on a project that he had put together with some other folks. The foreman said, “One of the things we check here, we want to make sure that everything’s API,” and he said, “What do you mean?” He said, “Is everything API? Is everything on the well site meeting API standards? Are all the operations as safe as they need to be?”

That always stuck with me, that that’s how a lot of people in the oil field see us. Is everything API? Does everything meet the standards that it needs to meet to make sure that we’re operating in the safest manner possible?

Russel: Yeah. We could probably do a whole podcast just on that conversation right there, David. I’ve certainly had the same experience. More than one time, somebody has asked me, is it compliant to API, and they cited a standard, and I didn’t know that standard.

David: Yeah.

Russel: For a vendor, if that happens, you’re like, why do I not know what that standard is?

David: [laughs] Exactly.

Russel: Standards change. Standards evolve. As you change your business, you change what you’re doing, then the impact of those things modifies.

David: Yeah, absolutely.

Russel: I want to ask you about the process. I know that as a standards organization, API is accredited. Maybe you can talk to us a little bit about what does it mean to be accredited, and what does API have to do to be accredited in terms of its standards?

David: Sure. We are accredited by the American National Standards Institute, or ANSI. ANSI is an organization, it’s actually a year older than API. It was formed a year before us in New York. It is the standards authority here in the United States. It has a memorandum of understanding with the Department of Commerce’s National Institute of Standards and Technology (NIST).

One of the things that they do is they accredit voluntary consensus standards organizations like API. You become an accredited standards developing organization — or SDO — through an ANSI process. What that requires is that you follow their four pillars for consensus standards.

You need to have openness. Openness for API means that anyone that has a direct and material interest in a standard has an opportunity to participate in the process, and that our standards meetings, with the exception of some of our policy groups or budget groups, are broadly open to anyone that wants to participate.

Russel: I want to underscore that, David. Sorry to interrupt you, but I want to underscore that.

David: No problem.

Russel: API standards committees are open even to non-API members, so long as they have an interest in the standard.

David: Yeah. The requirements to participate in an API standards development process committee is you have to have obviously technical competence in the subject matter. We need engineers that understand the subject matter being discussed, and you need to have the ability to participate in the process.

Since we’re a standards developing organization based in a trade association, we tie everything back to the member companies or the company individually. Whether you’re a member or not, you have to have that management support. They have to say this is important to us for you to participate in this process, so we’ll help you find time to do this work. It’s important work.

Yeah, openness is the first requirement. The second requirement is what’s called balance. What that means is that when you develop your standards, you have a balance of different interest categories working on the standard. You don’t want just the operators, or just the service and supplier manufacturers writing the standard. You want a balance.

At API, we follow what’s called the one-third, one-third, one-third policy where we look for one-third of the people around the table to be from the operators or the owner class, if you will — the oil companies or the pipeline companies depending on the standard. One-third from service and supplier manufacturers, depending again on the standard. Then one-third is called general interest. That’s pretty much everyone that’s not in the other two classes, but increasingly, that includes NGOs, that includes government representatives.

That includes, in the case of the public engagement standard, we have a lot of different interests there, of course, from around the pipeline world. That’s a very open classification, and includes your consulting engineers as well. We really want to balance around the table when writing these standards.

From a consensus standpoint at API, we define consensus as meeting approval of any standard’s action, and that’s revision or publication of a new standard to require two-thirds majority, and at least 50 percent plus 1 or at least more than half of those who are eligible to vote have voted. That’s our requirement for consensus.

We do all of our balloting, of course, through an online electronic system now. A lot of the folks that have been around a while will say, has the document gone out for a letter ballot? Because, literally, when I started, we would mail ballots, and then they would come back in, and we would count them and create spreadsheets. Now, of course, that’s all electronic. Our returns are much higher and approvals are much higher, but those are our minimums.

Then, finally, one part that’s really important that I don’t think everyone understands or appreciates is the due process. What due process means is that when you go in and you comment on an API standard — whether you’re a voter or a non-voter, whether you’re a member of the committee or not. We have a link on our website that’s called all open ballots. Essentially, everything that’s open today, you could go to and comment on.

We have a responsibility to provide feedback to each and every individual who provides a comment as to how their comment was treated and what the next steps in the process are. For some of our standards, we’ll literally have 1,200, 1,500, 2,000 comments on those really significant standards.

We do a very deliberate process of working with the committee leadership and the committee to consider each and every comment, and then to provide a spreadsheet on how they were treated, so that it’s a very, very transparent process.

Russel: I can certainly affirm that, David, as I have participated on a number of standards re-writes and such. It is a very thorough, comprehensive, deliberative process. I think it makes it challenging sometimes, too, because when you’re writing a standard, you’re trying to write a best practice, but you’re trying to write it in a way that it works for everybody.

David: Exactly.

Russel: That can often be a challenge in the level at which the words get discussed and parsed. It’s sometimes challenging. I find it interesting, though, as opposed to other things that I’ve read technically. Generally, I read an API standard, and I understand what it’s saying.

David: That’s good. That’s our intent. [laughs] That’s, of course, our goal.

Russel: That is no small thing, right?

David: No.

Russel: Because a lot of these things are very technical.

David: They’re very technical documents. That’s the first part of the ANSI accreditation, but it’s not enough for the ANSI accreditation for us to simply say that this is how we do our process, that it meets these four pillars of ANSI requirements of openness, balance, consensus, and due process. ANSI then follows up with an audit.

The API standards program is undergoing an audit. Actually, it’s early next year. It’s on a five-year cycle tied into the five-year cycle for the revision, review, or reaffirmation of standards.

What ANSI will do is they’ll come in and they’ll select a sampling of all of the standards that have been published as American National Standards since the previous audit. Then do a deep dive on each one of those to make sure that we’re following all of these things that we’ve got in our own procedures.

That we’re following all the ANSI criteria, and that we’re making sure that when people reference or use these standards, they’re comfortable to know they’ve really gone through this accredited process. I know I can trust the information in here, that it’s been fully vetted by a group of experts, and it really represents that industry gold standard or best practice.

Russel: Every standard that API produces gets an ANSI audit at some point.

David: What they’ll do is they’ll sample the standards that have been published as American National Standards since the previous audit. They can’t obviously review all of them. For example, this year, we’ve just about closed out the year on publishing. We’re right at 82 standards off-press this year. Last year, we had 90 standards.

We’ve been running roughly in that range for the last few years between 75, and 85, and 90 standards a year. They’ll do a sampling of the American National Standards and say, right, let’s make sure that API is fully following this process. Whether it’s an American National Standard, or whether it’s an API standard that’s not been published as an ANS, we still follow the same process.

We still look at openness, balance, consensus, and due process and really make sure that we’re following all those practices and procedures.

Russel: So, that’s 90 standards a year, give or take?

David: Give or take, yeah.

Russel: Knowing the level of effort required to push one of those out, that is a huge amount of effort. It’s a bit mindboggling, actually.

David: Yeah. We couldn’t do it, quite frankly…I obviously have a very dedicated team of standards engineers. Many of them have many years in the industry. Some, of course, are relatively new. Like most organizations, you’re always having some change. We really couldn’t do this work without the 7,000-plus volunteers on our database.

We have over 7,000 individuals who have been active on API standards committees over the years. They represent a little bit over 2,200 different organizations around the world. There’s no way that we could do this work on our own if we didn’t have all those experts really working hard through all these standards, revision cycles, and new standards to really help us produce these documents.

Russel: Yeah. I would bet that probably some significant portion of that number, a third to a half, are spending anywhere from 8 to 20 hours a month working on standards.

David: Yeah. We recognize that it’s an awful lot of work. A number of years ago, we created a years-of-service award program where we recognize all those volunteers that some of them may never, for whatever reason, become a task group, or a work group, or a sub-committee, or committee leader. We recognize them every five years for their years of service. To be honest, we’ve had some individuals between 45 and 50 years of service on API standards committees.

Russel: That’s incredible.

David: Yeah. One individual was explaining to me he’d literally attended his first meeting with his father, who’d also been in the oil and natural gas industry, when he was in his late teens, early 20s, went into engineering, and then joined the API standards committee and kept that tradition going.

In our last meeting for our refining committee last fall in November, we did have one individual with 45 years of service on an API standards committee, which is just unbelievable.

Russel: Yeah, it’s amazing. It’s amazing. I’ll transition us here. I could get spun out on that whole conversation.

Before I leave that, I think I will say this. I do think that reflects on just how committed the community is to improving how we operate. It really does demonstrate a significant commitment by all the players in this industry, both the operators and the vendors, that they’re putting their best engineers on these projects.

David: Yeah, that’s one of the other things that’s always impressed me about working on these standards committees with these volunteers. You’ve probably seen it as well, Russel, when you worked that.

Because they’re representing their companies, the companies send their absolute top specialists in whatever field it is that we’re working on. One of the great things about working on the standards committees, in addition to that sense of fulfillment of doing that good work is you work with a lot of really smart people. You walk out of the room a lot smarter than you walk in, if you know what I mean.

Russel: Yeah, absolutely. It’s one of the reasons I like doing the work because of the learning. The learning, it’s intense, but it’s very rewarding because you’re learning from the best. You’re learning about the state of the art. You’re learning what people are doing and why they’re doing it that way. The conversations in these rooms are generally very open and very frank.

David: Oh, yeah. You mentioned the commitment to safe operations, reliability, and sustainability. One of the API principles I’ll cite, too, that ties directly into our mission statement, is our principle to commit to enhance the integrity of operations across the industry by applying API standards, implementing workforce training programs, and participating in performance initiatives.

If you think about standards, they really are the foundation for a lot of this work that gets done to raise the bar for everybody so that everyone’s operating safer and with the best integrity that they can.

It’s very important for industry’s continuing license to operate that we demonstrate to the public, and to the regulators, and to everybody that we’re going to do our absolute dead-level best to make sure that all these operations are safe and sustainable, and as we like to say, that everybody goes home to their family at night.

Russel: Absolutely. You mentioned the regulatory community. How are API standards and PHMSA and the Pipeline Regulatory Committee, how are they alike and how are they different?

David: They’re alike in the sense that we’re all focused on safety. We’re all focused on making sure, as I said a minute or so ago, that everyone goes home to their family at night. The difference is that API standards and the use of API standards is entirely voluntary.

Unless somebody puts them in a regulation — and we’ll get to that in a minute — or puts it in a contract, or in a tender bid, or something like that, their use is entirely voluntary. They’re out there for industry to use, to take advantage of, to make sure that they’re really meeting that gold standard, but beyond that, there’s no requirement.

The regulators, of course, create regulations, and what regulations do is they do create, of course, a legal framework for how you need to operate. Because the API’s tradition of developing standards essentially since its formation, being formed as a standards-setting body in many ways, and this very rigorous third-party accredited and audited program that we go through, the regulators widely use the API standards.

They’re by and large the most widely cited standards in the U.S. and increasingly around the world in both federal, state, and international regulations, because they’re recognized as that gold standard. The regulators use them quite extensively.

Of course, here in the United States, once a regulator puts an API standard incorporated by reference into the regulations, then that is the requirement that you must follow. Speaking about a recent experience we’ve had with this, we all remember the gas leak in Southern California. I think it’s Aliso Canyon.

Russel: Right, the one related to the gas storage facility.

David: Exactly. API again working with our subject matter experts, they’ve got great vision. Actually, sometime before that incident occurred, we had just published two new standards on safe underground storage in these different kinds of caverns and facilities.

Once PHMSA went through a very reviewed rule-making process, it went out for public notice and comment on the proposed rule. When they finally published the rule, the rule said the API standards — these happened to be 1170 and 1171, which are going through a revision cycle because they’re coming up on their five years as well — anyway, in the final rule, they said this is how industry needs to manage these underground storage facilities. You need to follow API Standard 1170 and 1171, depending on the circumstance and the operation you have.

I think that really shows you that the regulators recognize the value of the standards. We often encourage their participation. Of course, they’re resource-constrained like everybody.

We’d love to have more regulators at the table than sometimes we’re able to get, but we do work very closely with the regulators so that they can understand the value in reference to standards where it makes sense for them to do that.

Russel: Certainly, I’ve been involved in some standards committee where there was a regulator involved, and sitting at the table, and participating in the conversation. That’s often quite interesting as well, and informative. I’ll just say that. Ultimately, we’re all trying to do the same thing. We’re all trying to improve safety and improve performance.

David: Yeah. Speaking of performance, I’ll just mention that one of our policies at API and a practice that we follow is that we really want our standards to be performance-based to the maximum extent where they can be.

What I mean by that is you can have performance-based standards and you can have prescriptive standards. Prescriptive standards are often used sometimes in a manufacturing environment where, for example, you have to have very specific tolerances, again going back to that threading example, going back to the strength of materials example and pipe and other things.

But then for operations, you really want to have performance standards. You want to tell people what they need to do, not necessarily specifically how they have to do it. We like to say that that way, the standards are more of a ceiling.

They’re things that people can reach for and they can innovate and find different ways to do, as opposed to what you might consider a floor, which would be an absolute. If I just do this, I’m in compliance with either the standard or the regulation.

We really want to create standards that are performance-based so that people are always innovating and thinking of ways that they can do things better and do things safer and more efficiently.

Russel: Right, exactly. Performance standards also require more thoughtfulness, and that they’re harder to write. They’re also, I think, sometimes harder for the community to understand.

David: That is absolutely true, but I will tell you that…

Russel: You need to know the background for the standard.

David: Yes.

Russel: Sometimes for those kinds of standards.

David: Yeah, but they’re also, in accordance with the government’s thinking as well, there’s a National Technology Transfer and Advancement Act, which encourages…actually requires, really, the regulators to use industry consensus standards when it meets their mission, but it also…the OMB put out a updated circular on implementation of the law.

In the circular’s background, it talks about performance versus prescriptive standards. They do encourage performance standards, because they recognize exactly the value that you’ve identified. While they’re harder to write, they’re better in the sense that they really give that opportunity for innovation and improvement.

Russel: Right. One of the questions I had for me to ask was why does it take so long to get a standard out? I think we’ve kind of already answered that question, David. [laughs] I think you’ve kind of covered that. Do you have anything you want to add to that? I’m sure that’s a question you get asked frequently as well.

David: Yeah, and it’s a very salient question. It’s an important question. It does take time to develop these standards because of the amount of work that goes into and the review process, the checks and balances to make sure that all the different interest categories are considered.

One of the things that we started doing a number of years ago was we’ve gotten better with some of our electronic tools is one of our key performance indicators now is called our standards development cycle times.

We’ve been tracking this very closely for a number of years. I’m happy to report that this year, for our 2020 off-press standards, we’re down about 12 percent from the time it took us to develop a standard from start to finish from 2019.

Right now, we’re a little over two-and-three-quarters of a year to develop a standard. That includes the time from project approval to publication date. Of course, the biggest amount of time there is what’s called pre-ballot phase, which is really the consensus-building phase. As you’ve said, you sat in some of those committee meetings. Some of that can be pretty tough sledding, but it does give you a great product at the end.

Russel: I think it’s also driven by the complexity of the standard and how quickly the technology moves.

David: True.

Russel: You think about something like the cybersecurity standard, which is working its way through on the pipeline side. How those guys can keep that kind of standard anywhere close to current and meaningful, it is really challenging because it changes so fast.

David: Exactly. We could not — in addition to the great leadership we’ve had from that group — we couldn’t have done it if we weren’t thinking about our standards from a performance-based approach.

Russel: Exactly. That’s exactly right.

David: Yeah. You could never write every specific kind of requirement in cybersecurity. The other thing that’s taken a little longer on that standard is we’ve moved it from what was basic SCADA-type security, which is important enough, to the broad Internet of Things cybersecurity.

When you think about all the different threats that all of our systems are challenged with now, whether it’s an overt act or an accidental act, like you walk onto the field site with your latest smartphone or gadget, and it’s got something in there that you’re not aware of, and all of a sudden, it’s talking to your systems, obviously, there’s a lot to protect there.

Russel: Yeah. I think it’s just a good illustration of why it takes the time it takes, because you’ve got to write these things in a way that they’re going to make sense when they’re published and have at least a 5 to 10 year life cycle the way they’re written.

David: Exactly. As I said, we do have that five-year cycle where all the standards have to be revised, reaffirmed, or withdrawn. You really want to write a standard that’s going to stand that test of time. There’s quite a bit that goes into it.

Russel: David, what do you think the future is related to API and its standards processes? Where is all of this headed? What should people be looking for?

David: I think what people should be looking for is as industry evolves, as we all work to determine how we can be more efficient, more sustainable, more reliable in an ever-changing world, I think we’re going to see standards in new areas. I’ve already mentioned a couple.

Of course, we have the additive manufacturing on the upstream side. On the downstream side, we’re doing a lot of work in risk-based approaches. If you think about how complex a refinery is, it doesn’t make sense to just have a simple checklist on when you do your inspections or your audits.

It might make more sense to tie that into what are the areas that are most likely to have problems or challenges? Those are the areas we should focus on. I think we’ll see more work in that area.

I think, quite frankly, we’ll see work in things like carbon capture and underground storage. CCUS standards I think may present an opportunity for API to really support the industry as we move forward. We all recognize what’s likely to be a lower-carbon — as they call it — future, because of the expectations of our stakeholders. We see opportunities there.

Of course, I’ve already mentioned public engagement, really looking at the full life cycle of that pipeline. We published a standard for hydraulic fracturing gor the upstream group a number of years ago that looks at the entire life cycle of a field, and much like that, we’re looking at that.

What’s that entire life cycle of that pipeline? How do you really get the public engaged so they support the activities that you’re doing and that they really feel like they are a part of the process?

Russel: Awesome. I think the way I’d like to wrap this up, API is our sponsor for the first quarter of 2021. David is the first guest we have to talk about API standards. We’re going to be doing several other episodes about specific standards that are either new standards or soon to be published as revised standards.

I’m really looking forward to those conversations. I’m just so blessed to have API sponsoring and participating. I’m really glad that we’re able to help get this word out.

David: Russel, I really appreciate the opportunity. I’m really excited to hear these other subject matter experts talking about these key standards that we’re producing. While we’re on the subject of standards and standards making, I’d like to thank you for your service working on some of the standards committees.

I know that, quite frankly, and this goes for you and all the other 7,000 volunteers, we recognize a lot of that work is done on nights and weekends. It takes you away from your family and your leisure activities, but it’s so vitally important. We just couldn’t do this work without the SMEs. Thank you very much for being an SME in the past, and hopefully, we can bring you back at some point.

Russel: I’m sure that’ll happen. You guys keep working on standards I’m interested in. I’m sure that’ll happen.

David: Great. Appreciate it.

Russel: David, thanks for coming on. It was great to talk to you. We appreciate the API and all you guys do.

David: Thank you so much. We appreciate the podcast.

Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with David. 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 would like to support the podcast, please leave us a review on Apple podcast or on whatever app you use on your smart device. 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 either by filling out the form on the Contact Us page at pipelinepodcastnetwork.com, or you can reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWords