4
The Elements of Project System Excellence
Edward W. Merrow, Founder and President Independent Project Analysis, Inc.
The three companies here today saved literally hundreds of millions of dollars during the 1990s by improving their project systems. What are the common elements they share? What are the things that have moved them forward?
In DuPont’s and Chevron’s case, they have found areas of true excellence. Weyerhaeuser has gone from being less than mediocre to being very solid and is on its way to becoming excellent. All three companies have lowered the capital cost of their projects. All are providing excellent operability of plants, something that has not really been mentioned very much. But the fact of the matter is, developing facilities that don’t operate very well is not much better than developing a facility you shouldn’t have built at all. Most importantly, all three of the companies represented on the panel have project systems that are responsive to their businesses. By that I mean the businesses provide direction, the businesses say this is what we need, and the project systems respond with the right project done well.
All three of these companies used to be underperformers. I’ll never forget when I first benchmarked DuPont, their projects proceeded in an expensive, slow manner but things worked at 200 percent of nameplate. And it was predictable. But with schedules and costs like that, anybody would be predictable. So a lot has changed at DuPont, at ChevronTexaco, at Weyerhaeuser. What are the key common elements they share? First, all three companies adopted a common process (Figure 4-1). It isn’t just a process for process’s sake. All three companies realized they needed to have a consistent and enforceable approach to projects, and they needed to have their own vocabulary. They needed to understand across all of the functions what things meant. At DuPont, when you talk
about FEL 1, everybody understands it is business planning. Everybody understands, because they have a common language.
One of the critical things that is problematic in project systems across the industry is the lack of cooperation across functions. The businesses don’t understand the engineers, the engineers don’t understand the contractors, operations doesn’t understand anybody. These three companies have a common language for talking about projects. The substantive work of their project systems is defined by their common project process. They also view their common processes as a controllable, manageable process. When people at all three of these companies think about control of the project system, they think of it in terms of statistical process control or statistical quality control, much as they think about controlling and improving a manufacturing process.
They understand the relationship between inputs, or things that feed the project process, and results. Because they understand the relationship, they can manage the project system via the front end.
Project systems by their nature, and especially major project systems, cannot be managed by results. Management by results is a good management consulting phrase, but it is absolutely hollow when it comes to projects. Projects must be managed by the leading indicators.
The critical leading indicator revolves around the front end (Figure 4-2). All three of these companies and other companies that excel in capital projects in the process industries are focused on the front end. And in one way or another, the front ends of all three projects systems resemble each other in their fundamentals.
First they try to define what they are trying to do. That is the business front-end loading. For DOE I don’t think it is basically any different. What is the fundamental objective? Not, what is the project? In fact, the most capital-efficient project is the one where I can meet the business need with no project at all. One of the characteristics of these companies is they look for that nonproject alternative as part and parcel of their project system.
Second, they have a steadfast commitment to excellent definition. They ask if that opportunity is real and what is it going to look like. Then, finally, they endeavor to work out all the details of how they are going to do this quickly with no change. Why this incredible emphasis on the front end? Let me put a couple of numbers around it. In the process industries—all chemicals, minerals, pulp and paper, steel—only about one project in five meets all of the project objectives promised to the company at authorization. That may surprise you. I think a lot of people have the view that vis-à-vis the government, the private sector does everything well. The bad news is four projects in five don’t meet all the promises that they make. The product costs more, the process doesn’t work as well, and people get hurt on the project. The good news is that the percentage of projects that meet expectations is up from about 6 percent 15 years ago.
Among projects that had completed the front-end work, how many projects failed to deliver? Two in a hundred. In other words, most projects do not go
astray in the field. Most projects do not go astray when we get into detailed design. The projects go astray up front. Almost all field problems can be traced back to things that we failed to do on the front end.
There is not a dichotomy between selecting the right project and doing the project right. Those two things go together. Front-end loading answers the basic questions for the owner: Why are we doing it? What are we going to do and when? How are we going to do it? Who is going to do the work? All of those questions have to be fully answered on the front end if they are going to be successful. It is one of the first orders of business. Front-end loading is a process, but it is also a set of products. It is very important to focus on the products when measuring front-end loading. It provides the basis, the platform, for doing the value-improving practices. It produces a design basis package, which is the basis for no change. It also gives you a baseline that you can honestly measure against and not a baseline to be rebaselined next year. In addition, it provides an enduring set of commitments made by the project organization to the business around project quality. It allows business, operations, and engineering to align their functions.
Finally, a poorly planned project is inherently a project that is at risk for safety problems. Front-end loading in the process industries is the vehicle for cutting out cost. Interestingly, we have seen that the relationship between front-end loading and reduction of cost has actually gotten steeper in the 1990s than it was in the 1980s. It is also the way that you take time out of construction, because front-end loading is fundamentally the way that you eliminate unnecessary change.
The goal of projects is not to have zero change. It is like what that much maligned baby doctor, Dr. Spock, used to say: If your goal is to never spank your children, you will probably spank them just about the right amount. Well, that is true with change as well. Our goal should be no change, but we will make changes, particularly in high-technology projects. And the high-technology projects are also the ones where it takes more owner muscle and involvement to make them go. Those are the projects that are very difficult to effectively pass to a contractor to simply execute according to plan.
In the private sector, the part of the front-end loading process that is done worst is trying to figure out what it is that you want to do. Sometimes after a project has failed because the price and volume forecast were wrong, business people will say: You can’t forecast the market. Our response is that’s your job and if you can’t do it, you need to find somebody who can. The fact of the matter is, if you do the diligent hard work in this first phase of front-end loading, you will have many fewer market surprises.
Most project systems are pretty good at this middle step, FEL 2. This is how you take an idea—good, bad, or indifferent—and turn it into a scope of work. Many people think that front-end loading is over at this point. It’s not. The third piece of front-end loading, FEL 3, which is the project planning, involves figuring out exactly how you are going to do this thing. You must ask: Do we have the right contractors on board? Is our approach to contracting correct? Do we know how we are actually going to start it up and who is going to do that work? Do we know how we are going to turn units over? All of this is planning work that must get done before you are ready to execute the project with excellence. This is the area that is the second area of weakness in the private sector in getting the front end done correctly. One of the things that I hope is clear from the presentations of my colleagues this morning is that the owner must have sufficient internal competence to control the front end of a project. And when I say control, I mean to really shape it. That means that you can’t eliminate all technical competence from the DOE organization and still have good projects. You must have technical competence in order to be able to do your projects well. You must be able to control the development of that front end and you must be able to control it right through the execution planning.
Contractors can do a lot of the heavy lifting, especially in FEL3. But contractors cannot figure out what you should do. They cannot figure out why you are doing it. They can’t figure out the details of how you are going to do it. And the more technically complex the project is, the more owner involvement is critical to the success of the project in execution. All this is for a very simple reason. There is no such thing as a high-technology project that does not have required changes in execution. It is a red herring, a fish that doesn’t exist. Changes will be required, because if we knew everything going in, it wouldn’t be a high-technology project.
A weak owner combined with a good contractor makes a bad project. Therefore, strength in the core competencies of the owner is absolutely essential to the development and execution of a capital-effective project, be it in the private or the public sector.
To sum up, first and really foremost, you have got to get the various parties aligned around what you are trying to do. You’ve got to use competitive technology or you are obsolete before you get out of the starting gate. You have to use the value-improving practices. And most importantly, you have got to front-end load, front-end load, front-end load. For real estate it is location and for projects it is front-end loading. The result, then, is the right scope to meet the business needs. You must get your contractors and your vendors involved early enough that they, too, understand what you are trying to do. You execute with discipline. The result is low cost, fast cycle time, and good quality.
Now interestingly, in all three systems safety and better returns on investment are coequal goals. It is absolutely essential I would argue, because part of what makes good safety is found back here on the front end, and you simply can’t avoid it. So if project excellence is so simple, Why—as the chairman of one of the big four oil companies asked me a couple of months ago—can’t we do it? It is obvious, but why don’t we do it? My answer to him, and I think an answer to almost all companies that have serious performance problems around their capital project system, is because you can’t develop the necessary level of cooperation within your organizations to do the job right. That is the single most difficult element of having an excellent project system. You have to all be in it together. There is no such thing as a good project system that belongs to the engineers. Every good project system belongs to the company, and to come full circle, this is why common process is so important. This is why, when the chairman says that the ChevronTexaco Project Development and Execution Process (CPDEP) is the corporation’s process, that it is a core value, and that it is the way the corporation is going to approach its work, it really makes a difference. Without that cooperation, it is virtually impossible to ever be more than mediocre.
Edward Merrow is the founder and president of Independent Project Analysis, Inc., a company that provides a unique project research capability for the chemical process industries. Over the 14 years of its existence, IPA has grown from a one-person organization to over 100 project analysts with offices in the United States, Europe, China, and Australia.
After receiving degrees from Dartmouth College and Princeton University, Dr. Merrow began his career as an assistant professor at UCLA, where he taught mathematical economic modeling and industrial organization. After 4 years of teaching, he went to the RAND Corporation, where he developed and directed
RAND’s energy program and research program for the chemical process industries. After 14 years, he left RAND in 1987 to start IPA.
Dr. Merrow has been active in the American Institute of Chemical Engineers as a panelist, panel chairman, and contributor to Chemical Engineering Progress. He has testified before the U.S. Congress in matters pertaining to overruns in major capital projects and served as a panel member for the National Academy of Sciences/National Academy of Engineering on the analysis of project risks. He was the 1998 recipient of the Construction Industry Institute’s highest honor, the Carroll H. Dunn Award for Excellence. In 2001, he received the American Institute of Chemical Engineers Engineering & Construction Contracting Division Award for “outstanding contributions to the industry.”