Project Management Institute

Evolution toward effective project management in turbomachinery projects


In oil, gas or petrochemical projects, turbomachinery is usually on the critical path, and is often considered the heart of the process. While some of this turbomachinery is greatly standardized (such as combustion gas turbines) much of it is custom designed for the specific application, such as the centrifugal compressors and steam turbines supplied by the author's company. Because of the critical nature of this equipment and the processes it enables, suppliers are almost always asked to provide not only the core turbomachinery but also all related machines and auxiliaries, and are expected to accept unit responsibility (as defined by API Standards) for the successful integration of their scope within the larger project. This can also be interpreted as Total System Responsibility or TSR (Seely & Duong, 2001, pp. 35–36) for the defined scope. Exhibit 1 illustrates one typical type of customized turbomachinery package.

The design, procurement, manufacture, test and documentation of such a turbomachinery system thus becomes a unique project in itself within the larger overall project, with the contract serving as the project charter (PMBOK®, The intent of this paper is to describe the evolution toward more intentional project management (as opposed to “accidental” project management) in the author's company, and to offer suggestions to improve integration of this equipment within the total project.


Like many companies, our project management evolution began roughly 20 years ago, with “contract administrators” who were responsible for coordination of orders with customers. Without any particular authority or training, these individuals dealt mostly with administrative matters, and in the days of the sellers' market this seemed adequate. As market conditions changed, manufacturers recognized the need for more control over orders with ever-tighter budgets and shorter schedules. Many things were tried—some successful, some only fads. The contract administration group was renamed project management, and more was intuitively expected of the new project managers, but authority and training were still lacking. Procedures were tried, and if they worked they were kept; if not something else was tried. This led to some successes but many frustrations, best described by one of our PM's as feeling more like a project “bystander” than a project manager.


Several years ago we began a series of steps which placed us on the PMI® path. The first was to seek out professional training in project management—this led us to the IIL® PMP certification course. All our project managers completed this course, and several went on to achieve PMP certification. Today we require all project managers to complete the certification course, and are gradually extending this to include our project engineers. We also arrange continuing training for all project managers, both to enhance their skills and to support PMP recertification. This training has included a videoconference course on risk management, and participation at SeminarsWorld 2002.

Procedures, Processes, Practices

Frequent references during training classes to PMI® and the PMBOK® Guide led us to look further in that direction, and of course we discovered that problems we felt were unique to us were actually quite common within the project management community. One of our next steps was to evaluate how our standard processes and procedures stood up to our recent training. To do this we expanded the PMBOK® Guide table of process groups and knowledge areas (Figure 3.9) and listed our own company and departmental practices (as documented in our ISO 9001 certified quality system) in the process groups and knowledge areas we thought were applicable. The resulting cross-reference table has served us as a road map toward continuous improvement in our project management practices. The current version of this table is shown in Exhibit 2. We found that many of our existing practices were sound, while the table exposed areas needing more formal development. Several of those areas are discussed herein. Overall we established the PMBOK® Guide standard practices as our guiding principles in project management.


To improve our project focus and team coordination, we combined all the elements with direct customer interface into one group called Project Operations. This united the project managers with project engineering, systems engineering and drafting, technical publications and document management. While our project teams still include some functions that are assigned from other departments on a matrix basis, the personnel that are involved in day-to-day project integration activities are within the Project Operations group. This has enabled more effective communication and understanding of project principles such as triple constraints.

Exhibit 1. Air Compressor System

Air Compressor System


Because turbomachinery systems are most often on the critical path of the customer's project, adherence to schedules is always of prime importance. Competitive pressures have combined with a tendency toward longer decision-making times on large capital projects, resulting in ever-decreasing lead times for our products. To meet these challenges a more comprehensive planning process was developed and implemented. The core of this process was the establishment of a dedicated planning department, with links to both project management and the functional areas (engineering, procurement, and manufacturing). Exhibit 3 illustrates the basic planning process.

Change Control

One of the areas that we found lacking in our processes was change control. The nature of our business is such that many scope definition details are left somewhat open to interpretation at the initiation of a new project. We will come back to this later in our suggestions for improvement, but for now we will consider this a “necessary evil” that must be dealt with. On every project we go through a drawing submittal/review/revision/approval process that may take several rounds before every single technical detail is resolved to everyone's satisfaction. Such details are almost never related to the core machinery design, but rather to such topics as instrumentation and piping, where there are many possible variations. During this review process, we must proceed with procurement and manufacture in order to meet schedules. Most drawing comments during the review process are simply clarifications, but occasionally someone on the client's technical staff (who may or may not have any appreciation for the project's overall schedule or contractual considerations) requests a significant change that could have an impact on our schedule and cost.

We found that our existing processes in this area dealt primarily with after-the-fact documentation and implementation of such changes, but that proper impact definition and proactive management of the change process were on an ad-hoc basis. We implemented two major changes to our procedures. First, we formalized the process of evaluating and communicating the impacts of any requested change, as shown in Exhibit 4, and developed a controlled form for this process. Originally communication of change requests was via email, but recently we have developed a web-based portal system that automates the process.

Second, we developed a change control policy that is included in our proposals and discussed in detail with the customer early in the project. This policy includes the requirement for identification of the authorized individual on the customer's team that will manage all changes in concert with our project manager. It also includes the definition of various design “freeze” dates, to be agreed by all parties. The key elements of the policy and our process are:

•   Identification of a change control strategy as an important issue for the success of the project

•   Shared ownership of the strategy by our company and the customer

•   Recognition that the impact of a change varies greatly depending on when it is made.

Exhibit 2. Comparison of Company Standard Practices to PMBOK® Guide

Comparison of Company Standard Practices to PMBOK<sup>®</sup> Guide

Exhibit 3. Planning Process

Planning Process

Risk Management

Traditionally the area of risk identification was formalized only from a financial perspective, and there was no process to try to manage the risks associated with a project; any attempts at mitigation were usually initiated on an intuitive basis. After being exposed to the basics of project risk management in the PMP® certification course, we knew that we had a lot to learn in this subject. Our project management staff then enrolled in the Strategic Edge Project Risk Management Course conducted via videoconference by IIL. Following that training we started to develop our own risk management process. We ended up with a fairly simple procedure utilizing brainstorming techniques, similar to the process described in a recent article (Martin & Tate, 2001, p. 18), to identify and assess potential project risks and develop response strategies. The procedure is performed shortly after receiving an order for a new project, and the project manager then monitors the project for changes that may impact the risk management plan. Software was obtained to conduct Monte Carlo simulations when necessary to provide quantitative risk assessment.

Customer Satisfaction

One of our challenges was to obtain more meaningful feedback regarding customer satisfaction (as defined in PMBOK® Guide, Chapter 8, p. 97), in order to fuel our continuous improvement quality system, and to comply with the latest ISO 9001 requirements for a customer satisfaction process. Previous procedures using faxed or electronic surveys had met with limited response from our customers. After considerable research, we located a consultant, Essential Resources LLC, which specializes in developing and maintaining effective customer feedback processes. Working with them we developed three surveys for the beginning, middle and end of our projects. We concentrated the surveys on particular PMBOK® Guide process groups:

Survey I—Initiating (shortly after order is received)

Survey II—Planning, Executing (mid-project; following issuance of certified drawings)

Exhibit 4. Change Request Process

Change Request Process

Survey III—Executing, Controlling, Closing (at project completion, after delivery).

The surveys are conducted by the consultant's staff via telephone interviews. The surveys have been designed to focus on a few key concepts in each process group, and take only a few minutes for each customer stakeholder contacted. Each survey includes questions to solicit comments and complaints, which are reviewed in our Corrective/Preventive Action Process to identify and act on generic problems. All survey results are considered in our Lessons Learned meetings conducted at the conclusion of each project. This feedback is in turn included in our Risk Management evaluations for new projects.

Participation by our customers has been a huge improvement over previous feedback procedures, and is attributed to the skill and training of the independent interviewers as well as the brief, focused interviews. While the survey feedback can be and has been evaluated on a statistical basis, we have found the specific comments and complaints to be most invaluable in understanding our customers' perspectives and improving our processes accordingly. Several processes have been developed or modified based on this feedback, such as:

•   Revision to our Customer Inspector Policy

•   Requests for more detailed schedules from our suppliers

•   Development of a new Communications Procedure

•   Suggestions to Marketing for proposal improvements.

Lessons Learned

Learning from experiences on past projects had always been informal and inconsistent, often based more on hallway folklore than actual fact. A Lessons Learned process was instituted that involves a brainstorming session with the project team at the conclusion of the project. All discussed items are documented and made available to all project managers for reference. Those items are considered for possible generic root causes in our Corrective/Preventive Action process, and are also taken into account in our Risk Management review on new projects.

We also review various PMI® and other industry publications for articles of relevance to our work, and keep a central library of such references, with updates communicated to all project staff.

Corrective/Preventive Action

The core of our continuous improvement program is the Corrective/Preventive Action review process, which is an integral part of our overall ISO-certified quality system. In this process each functional group or department conducts a quarterly review of their quality system records to verify corrective actions for specific problems, identify generic problems, and implement preventive action plans to remove the root causes of those generic problems. This process had been in place since our first ISO certification, but had always focused primarily on problems of a technical or internal systems nature, because such problems were the most definable, through records such as engineering change orders, manufacturing nonconformance reports, and post-delivery backcharges. The implementation of our Customer Satisfaction, Risk Management and Lessons Learned processes has allowed us to expand our continuous improvement efforts into the “softer” areas of Project Management. With multiple projects in all phases at any given time, the combination of these processes lends continuity to our entire program.

Improved Integration

The results of our project management evolution so far have been very encouraging, as evidenced by customer satisfaction feedback, on-time statistics, and other indicators. Our project management growth process and training has also reinforced our intuitive belief that many of the things that have the most important influence on the success of the project occur prior to the clock starting on the purchase contract. This belief has led us to be much more proactive in preorder activities. A sales planning process has been established that monitors via weekly meetings the status of all potential new orders, and the project manager is often involved in final technical and commercial meetings with the customer. Now that we are learning to speak the same PM language as that of our customers, we believe there are steps that can be taken during the inquiry, pre-award and execution phases of the equipment purchase that can benefit both parties and improve the integration of our project into the overall project.

Project Manager Involvement

Despite the critical importance of turbomachinery equipment to the ultimate long-term success of the overall project, many times the procurement of such machinery is treated like a commodity purchase, with little or no involvement by the customer's project management staff. This is entirely understandable because of the breadth of demands on the buyer's PM, but it is sometimes frustrating because we have difficulty finding project stakeholders who can truly appreciate and support a discussion of concepts such as change control and risk management. This becomes especially noticeable in those projects where the ultimate customer's responsibilities have been largely delegated to intermediaries such as engineering and construction contractors (Berggren, Söderlund, & Anderson, 2001, pp. 40–41). We have found that those projects where our PM has an involved opposite number with strong project management experience are often our most successful projects.

Specification Conformance

All turbomachinery purchases involve some amount of technical specifications. Usually these include applicable industry standards (such as API, ASME, NEMA, etc.) as well as the purchaser's own detailed specifications, which often build on the basic industry requirements. There may be core technical specifications on the major machinery, and project or site-specific specifications on many technical subjects (such as piping, instrumentation, electrical, controls systems, etc.). When the end user has delegated purchase of the equipment to a consultant or contractor there is often another whole set of specifications from that entity.

Sometimes the purchaser has sorted out all the varying specification requirements and resolved potential conflicts prior to issuing the RFQ. However, all too often this is not done, and is left to the manufacturer to address in their bid. This can even include the manufacturer having to guess at the applicability of entire specifications that were included in the RFQ “just in case.” For our part, manufacturers have our own design standards, which are usually in general agreement with prevailing industry requirements. When a customer specification requires a different technical solution in a particular area than the manufacturer's standard, the manufacturer must decide when making the bid whether to comply with the customer requirement (which may have a cost, schedule or technical risk impact) or take exception to it. This often leads to proposals having many pages of comments, clarifications and exceptions to specifications, which generates frustration for the purchaser trying to review and reconcile all the bids received.

Unfortunately, our continuing journey toward more effective project management can increase the frustration level. This is because all our various processes and feedback channels continually remind us that “the devil is in the details,” so one way that we can become more proactive is by continually emphasizing and supporting more thorough specification review in the proposal process, which leads to still more comments, clarifications and exceptions. A question may now occur to the reader: why not just include the additional impact of the customer specifications in the bid, so the proposal is in complete compliance? This sounds like the obvious answer, except:

•   There may be conflicting requirements in the various layers of specs, requiring clarifications

•   There may be technical requirements that in our experience pose an unacceptable risk

•   It may not be obvious from the RFQ whether the buyer is more interested in specification compliance or minimum cost and/or lead-time. Given the highly competitive nature of most turbomachinery purchases, manufacturers cannot afford to make the wrong assumption.

From our perspective there is no easy answer to this difficulty; the real question is where and when should the effort be made to resolve it. It may look attractive to the purchaser to deflect this work to the manufacturer via the RFQ process, but in reality this may mean that the purchaser spends as much or more time working toward a resolution with several potential suppliers, as they would spend sorting spec conflicts out before the RFQ is issued.

Scope Definition (and Redefinition)

Related to the specification conformance issue is the subject of scope definition first raised in the Change Control section above. Many of the technical details that lead to change requests originate because of difficulties in specification interpretation. Others stem from customer attempts at scope “redefinition,” for various well-intentioned reasons. Such changes are well understood by the project management community to be major contributors for project cost and schedule overruns (Rad, 2001). Many of the processes we have implemented have increased our ability to detect such scope creep sooner (Weaver, 2002). However, getting people on the customer's side to pay sufficient attention to such issues before they become potential “showstoppers” is often an illusive goal. This is in part because day-to-day project communications are mostly concerned with technical and scope issues that involve specialists on the customer's team who are not usually trained in project management and are always focused on the issue at hand. We welcome participation from the customer's team of someone who can afford the time to see beyond the immediate issue and work with us to control changes for the overall good of the project.


We have given an overview of our company's journey toward more effective project management. We are confident from our successes so far that we are on the right track, and we intend to continue to improve our processes as we gain more knowledge and experience. While much of what we have learned could be considered logical or intuitive or common sense, we recognize, like our customers, that success depends on a structured process (Lavingia, 2001) and its disciplined use (O'Donnell, 2002). We have discussed some of the areas where we think improvement in the integration of our project into the larger project is possible. The key to such improvement is simply more effective communication between the manufacturer and the customers, using our common PM language as the basis.


Seely, Mark A., & Duong, Quang P. 2001, June. The Dynamic Baseline Model for Project Management. Project Management Journal, pp. 25–36.

Martin, Paula, & Tate, Karen. 2001. A Project Management Genie Appears. PM Network, August: 18.

Berggren, Christian, Söderlund, Jonas, & Anderson, Christian. 2001, September. Clients, Contractors, and Consultants: The Consequences of Organizational Fragmentation in Contemporary Project Environments. Project Management Journal, pp. 39–48.

Rad, Parviz F. 2001, September. From the Editor. Project Management Journal, 3.

Weaver, Peter. 2002, January. Vanquishing PM Nightmares. PM Network, pp. 40–43.

Lavingia, Nick J. 2001. Pacesetter Project Performance. Proceedings of the PMI® Annual Symposium.

O'Donnell, Richard. 2002, January. ExxonMobil: A Study in Project Management. PM Network, p. 46.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA



Related Content