Volume: 4 | Issue: 3

Standardization vs. Innovation vs. Optimization: Buying or Building Your Dream Car

I have been on a mission for a few months to study project complexity. Let me use the analogy of the search for a dream car. Search as you might, you likely cannot find a car with everything you want, but several cars may have features you like.

Because you do not want to make compromises in your dream car, you decide to combine all the preferred features into one car. You choose a powerful engine from a model, a transmission from another, and the body from another. You hire a team to put it all together. Since the engine does not fit into the chosen body, the team adds a few inches to the chassis. The color is not quite right, so the car is repainted. Many annoying problems occur during integration and commissioning; your team fights through them. Add in the latest and greatest sound system, the Corinthian leather seats, and a few cosmetic modifications and your dream car is complete.

There are several things we can say about this car with little fear of being wrong:

  • It will be more expensive than you could have predicted even in your worst nightmare.
  • It will take far longer to build than you dreamed.
  • It will not work nearly as well as all the rejected standard cars.

A custom-build car is akin to a typical deepwater project.

Project Failures

I have seen stunning data reported by Independent Project Analysis (IPA). IPA considers a project to be a success if the cost and schedule are each less than 25% over budget and the facility produces more than about 80% of nameplate in the first 2 years of operation. Only in baseball are the success criteria looser than this. Nevertheless, even against these lax metrics, 80% of projects are considered failures.

Complexity is not the entire cause of this, but I am convinced that it is an important cause and that the more we can simplify and standardize our projects, the better off we will be.

Complexity at OTC

As I walked the exhibition floor of the Offshore Technology Conference (OTC), I recalled many good times as a young engineer walking those same halls with a mission to learn. For many years, I attended with a single goal in mind. For example, one year, I wanted to learn all I could about flotation systems and in another year, I focused on lease automatic custody transfer (LACT) systems.

I do not generally have such goals anymore.

My main focus this year was to think about complexity and standardization and seek the perspectives of others. A friend of mine attended the OTC with the same mission; he chose to attend paper presentations and panel sessions about complexity and standardization.

There was a great deal of talk in the sessions about the need for standardization, simplification, and cost saving. I had mixed feelings while walking the floor. Many people with whom I talked agreed that things are overly complex and that we need to simplify and standardize. On the other hand, most vendors were eager to hype the next big thing, or their elegant, if subtle, improvement to a commodity product. And I must say that I was easily seduced by the novel stuff. I felt like what a recovering alcoholic must feel at a boisterous bachelor party—sure that the path of simplicity is the true path, but drawn to the bright, shiny, new stuff.

It has been 15 years since I have designed anything myself, and I miss those days. I understand the drive of every engineer to make a design as good and as fit to the environment as possible. But it is time for a change.

We were seduced by high oil prices and took our eyes off the ball. Our projects are too complex, too expensive, and take too long to complete. We cannot continue on the path we have been on and continue to be successful as an industry.

Having said that, it is not yet clear to me how we should go about doing it.

What Does Standardization Mean?

It is ironic that the word “standardization” has many different meanings such as follows:

  • The ultimate standardization is to duplicate an entire platform (standardize the final product).
  • Standardization is done on the system level (each system is a standard design or several standard designs, perhaps of varying size or materials of construction). The project is a nonstandard combination of various standard systems.
  • Equipment specifications are standardized (for instance, each separator is similar; the project determines which separators to use).
  • Component specification is standardized such as an industry specification for high pressure/high temperature (HP/HT) forgings.
  • The execution plan is standardized.
  • Project organizations are standardized by using the same vendors and contractors from project to project to capitalize on established relationships.

Inherent Project Complexity

So what might standardization look like in the oil field? All projects produce and separate oil, gas, and water. Some require waterflood, gas reinjection, artificial lift, enhanced oil recovery, subsea production, or subsea processing.

This is clearly not a one-size-fits-all industry. Try as we may, projects will be different because of significant differences between fields. Two fields will rarely be similar enough to duplicate an existing project. The analogy of building a bespoke car is inapplicable at the project level.

Standard Execution Plan

Could the real answer be as simple as being more disciplined in project design? In his book, Industrial Megaprojects: Concepts, Strategies, and Practices for Success, Edward Merrow made a strong case that an effective front-end engineering design (FEED) nearly guarantees project success.

This has been a mantra for some time now; a mantra that I think most people in the industry agree with. But this wisdom has not improved project outcomes. I am reminded of a line from the movie, The Princess Bride: “You keep using that word. I do not think it means what you think it means.”

It is clear that different teams and different operators have different concepts of what it means to finish FEED. And you cannot take the credit for doing the FEED if you change the design after sanction.

Standardized Systems

So, if we cannot simply drive a project off the lot or copy someone else’s design, we could seek to standardize at the systems level. To be fair, a lot of that already happens. We have standard trees and subsea manifolds. Topsides separation processes all look about the same (on the piping and instrumentation diagrams, at least). We are good copycats on the latest high-tech stuff; high-pressure, high-volume water injection pumps are always the same as, or very similar to, an existing successful pump.

At the next level down, systems become bespoke. An operator may use a tried-and-true water injection pump, but invent a new control strategy, route piping with little regard for water hammer issues, or select a less expensive overboard valve without proper regard for taking an
8,000-psi drop across a single valve.

And sometimes, the novelty is also at the next level down such as when an operator takes an existing successful product, but wants a different O-ring material, seal design, or lube oil pump. The vendors produce different products for different operators. This leads to vendor and third-party inspector confusion. Package engineers cannot keep up. Ultimately, no one is getting what he or she wants.

It will not be an easy journey; however, it is one that we must take together to be successful. The poet Rudyard Kipling wrote, “He travels the fastest who travels alone.” Not so for the journey our industry must take. Instead, I suggest, “He who travels the same path with the same companions travels the fastest, farthest, and with the least risk.”

Key Standard Specs and Optimization

At least, a group of operators, contractors, and forge masters is seeking to establish specifications for forgings used in HP/HT applications (see “Forging of Subsea Equipment: Standardization of Specifications Aims To Improve Delivery Time” by Pam Boschee, Oil and Gas Facilities, April 2015). This would clearly be a step forward, allowing manufacturers to build and stock forgings, and potentially saving weeks or months off the critical path for tree construction.

There are bound to be other areas in which industry agreement on a key specification would have significant benefit for all.

Many might argue that standardization will stifle creativity, and creativity drives the industry in many ways. For example, creativity has driven the advances made in shale fracturing practices. I do not consider the argument as meaningful. Standardization may have the opposite effect: It may increase innovation.

Innovation often comes in the form of a small step away from a tried-and-true solution.

“Optimizing” is a word that I hear too often. How can we be optimizing topsides designs when our understanding of the subsurface is +20%, at best? If it precludes optimization, standardization may be a good thing.

Emergent Behaviors/Effects on Systems

An old paradox, “our greatest strengths can also be the source of our weakness,” captures succinctly the need for systems thinking. It is easy to view standardization and simplification as the miracle cure for our project ills. But we need to be careful. Making things more complex frequently seems like a good idea because we do not fully understand the effects of complexity on our systems. However, there may also be unexpected effects on our systems as a result of simplification. I am unable to think of any, but that is my point: Effects on systems are difficult to predict.

Availability of Resources

I have been challenged with the view that simplification could put people out of work. Simpler projects presumably would require fewer people. Although it may well be the case for an individual project, many projects are routinely understaffed. A benefit of simplification may be allowing the time required for people to do their job, and if we make projects less expensive, capital may be available for additional projects.

I will continue to discuss complexity in this column and use other avenues to stimulate conversation. For instance, complexity will be the topic of the annual Projects, Facilities, and Construction dinner at the SPE Annual Technical Conference and Exhibition in September. I hope to see you there.

In the meantime, I am eager to hear your thoughts on the subject.

Howard Duhon is the systems engineering manager at GATE and the SPE technical director of Projects, Facilities, and Construction. He is a member of the Editorial Board of Oil and Gas Facilities. He may be reached at



Don't miss out on the latest technology delivered to your email every two weeks.  Sign up for the OGF newsletter.  If you are not logged in, you will receive a confirmation email that you will need to click on to confirm you want to receive the newsletter.