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:
A custom-build car is akin to a typical deepwater project.
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.
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.
It is ironic that the word “standardization” has many different meanings such as follows:
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.
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.
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.”
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.
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.
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 firstname.lastname@example.org.