Many process control application projects experience cost overruns, late completion, difficult startups, failure to achieve promised operating performance, and high maintenance costs. The causes include poor definition, scope changes, difficult technology issues, unexpected problems, and many others--all of which are actually due to poor project management.
Failures in process control project management are becoming worse as younger engineers who are more adept at the new technologies but have little feel for even informal project management concepts are finding themselves in lead engineering roles. At the same time, owners are requiring more competitive fixed-price work and shorter schedules, and are putting much more emphasis on achieving expected project results.
General project management techniques have improved significantly in recent years through the work of the Project Management Institute (PMI), the Construction Industry Institute (CII), and other groups. At the same time, many areas other than facility engineering and construction are discovering the discipline, and all seem to be putting more emphasis on good project management. Along with improved techniques, there is much more emphasis on:
* The role of the project manager as the person in responsible charge, not just a referee for problems.
* General management skills such as team-building, motivation, and communication.
* Comprehensive planning and control of the entire project including cost, not just schedule (as was often the case in the past, particularly for non-capital projects); quality (really working to manage it); risk (not to be feared but as just another feature of projects to be managed); scope (documentation); and change management.
* Using projects and project management concepts to manage much of the work of a company, not just things that have traditionally been done as projects.
* The Project Management Office (and its financial benefit) to support common methodologies.
PMI was formed just over two decades ago. Its membership has been growing at an average rate of more than 20% per year and is now nearing 100,000. The flagship PMI document, A Guide to the Project Management Body of Knowledge (PMBoK) (1), has a circulation of nearly one million copies and is the worldwide standard for methodologies and terminology for all types of projects. PMI certification for project managers, the Project Management Professional (PMP), has done a lot to disseminate the PMBoK terminology and methodology. More than 50,000 project managers met the rigorous requirements of experience, eduction, and testing needed to achieve PMP certification.
Process Control Projects Deserve More
However, process control application projects often have little formal project management. In fact, the lead engineer may be so focused on technology that he or she tries hard to avoid any project management responsibilities at all. It is even less likely that newer techniques are implemented.
Process control projects typically include some or all of these tasks:
* Gather data from an operating manufacturing plant via sensors.
* Use those data to automatically do something to the operation.
* Convert the data into knowledge to better manage and improve the operation.
* Integrate with the supply chain.
* Provide a fully functional operator interface.
* Manage plant assets.
These projects are called by a variety of names including industrial automation, instrumentation and control, automation and control, control systems, or process automation as well as process control. They have so many differences from other types of projects that even the best generic project management techniques are not enough. And while the PMBoK fully applies to nearly all projects including process control, extensions to the PMBoK are encouraged and have been developed for a number of specific areas--but not yet for process control. Little information specifically on process control projects has even been published. One of the few sources of specific information is a new ISA course.
Ten special characteristics of process control projects (Table I) are covered here with some techniques for handling each one. Some of these techniques are generic and some are unique to process control. The techniques apply equally to situations where the lead engineer is working for an internal customer, and where the lead engineer is a systems integrator or consultant and the customer is the lead individual employed by the owner.
1. Big Opportunity
Process control can deliver significant manufacturing cost savings in raw materials, energy, and labor; capacity increases without capital expenditure; supply chain improvements; and/or product quality and other strategic improvements. You should:
* Assign process control engineers to manufacturing units to work on long-term improvements. (A good rule of thumb is one process control engineer for each $50 million of product.)
* Ensure the process control engineers in manufacturing avoid firefighting and just working on routine small projects. (A good rule of thumb is that each engineer should deliver $50k of new benefits for each month worked.)
* Recognize that while benchmarking and plant assessment indicate how a plant's control and information systems compare to current best practices, these techniques will not identify specific benefit opportunities in a particular plant, and can even lead to improvement projects with little real value.
* Use a specific, formal methodology for identifying and prioritizing opportunities, using outside expertise if needed, and only implement projects with real benefits.
2. Lots of Hardware and Software
Process control projects have many components to select, specify, purchase, integrate, debug, and install. The task of determining the optimum choices of equipment and software is challenging, and mistakes may be made due to the sheer number of things to keep track of. You should:
* Complete high-level design (front-end or basic engineering) before any detailed engineering is done.
* Pre-select and partner with suppliers whenever appropriate so more joint effort can go into selection, specification, and installation design.
* Develop a detailed procurement plan.
* Develop a detailed quality control plan.
3. Technology Changes Rapidly
Projects often involve doing things for the first time. There is risk that systems or equipment will not work as expected or advertised, particularly in combination. The capabilities of the systems may not be fully exploited due to lack of knowledge. Debug activities can be difficult and lengthy, with risk of significantly increased costs and schedules. Engineering performance may be lower than expected because of unfamiliarity with the technology. You should:
* Work out all the unknowns before working on the familiar areas.
* Ensure that the technology is understood before doing any detailed engineering.
* Implement a thorough risk management program: treat risk as another aspect of the project to be managed.
* Realize that it is not possible to accurately estimate cost and schedule until technical unknowns are worked out.
4. Real-Time Data Acquisition and Control, Possibly High-Speed
This can mean outstanding reliability, integrity, and on-stream time. There is an absolute requirement for response times that match the needs of the manufacturing operation, and potential for conflicts between process control and information technology (IT) systems. You should:
* Develop a network schematic early in the project that protects the integrity of the control system.
* Work closely with IT personnel to use the best networking and systems technology available.
* Determine ways to fully test the system before installation.
* Provide outstanding documentation and training to plant personnel so the integrity of the system can be maintained.
5. Custom Software Development
Many choices for exactly how things are done can cause inefficient configuration/programming and extensive rework if changes are made. You should:
* Fully determine what is to be done in the Customer Requirements Definition and detailed functional specifications before beginning any programming.
* Use standard approaches for alarm and abnormal condition management to improve integrity and reduce the number of decisions that have to be made on each project.
* Define testing procedures to ensure compliance with the functional specifications.
* Realize that in spite of best efforts, strange and unexpected problems may surface during operation. Therefore professional burn-in support should be available long-term as needed, preferably from the team doing the original design. This can easily be six to 18 months.
6. Intangible Deliverables
Milestones are difficult to quantify, and programming efficiency varies from person to person. This can cause difficulty estimating and controlling the cost and schedule. Historical and parametric cost and schedule information may not be useful. You should:
* Break work into small activities (eight to 80 hours per activity is a good rule of thumb).
* Do cost and schedule estimating against that activity list. (There is simply no other way to estimate and track reliably.)
* Measure progress using earned value and with no credit until an activity is complete. (Process control activities often appear nearly complete when there is still a lot of work to be done. The last 10% is a killer.)
Figure 1: Project Constraints
Treat customer satisfaction as a constraint in addition to the usual triple constraints of scope, cost, and schedule. Quality should be treated as an absolute to be achieved, not something to be balanced against cost and schedule.
7. High Customer Involvement and Expectations
Process control projects require a high level of detailed information from the customer , and the customer often expects fantastic results. It can be difficult to get all of the needed customer input early in the project, and that can lead to difficulty meeting all the customers expectations. The customer may require a completion date earlier than can be logically scheduled or a cost lower than can be realistically budgeted. To top it off, the customer may require a lump sum price before the details of the work are fully defined. You should:
* Hold a good kickoff meeting using an outside facilitator and develop customer satisfaction metrics.
* Ensure a complete Customer Requirements Definition and determine what customer input/approvals will occur after this Requirements Definition.
* Treat customer satisfaction as a constraint in addition to the usual triple constraints of scope, cost, and schedule (Figure 1). (Quality should be treated as an absolute to be achieved, not something to be balanced against cost and schedule. Grade can, however, be varied, but that is part of scope.)
* Work and control only to a feasible, though possibly very aggressive, budget and schedule. Reject the concept of "just try to do it" to impossible budgets or schedules. (Projects attempting impossible cost and schedule targets often cost more and take longer. This is because these projects cannot be properly managed and activities are done out of proper sequence which causes a lot of rework.)
8. Integration Across Department Lines
There may be many customers and stakeholders in different areas with different objectives and expectations, and it may be difficult to get all departments to fully review and accept the same plan. You should:
* Hold a kickoff meeting including all stakeholders and using an outside facilitator.
* Ensure everyone buys into the Requirements Definition.
* Develop a complete Network Schematic early in the project.
9. Large Potential for Interacting Changes
Changes are likely, and changes in one area generally affect other areas. This leads to disruption of the work due to changes after the design freeze at the end of front-end engineering; changes because the customer wants details done differently, not just for additional features; mistakes due to not implementing changes across all impacted areas; and rework causing lots of extra effort. You should:
* Do front-end engineering, including detailed documentation of how the system will work, screen designs, specifications, and many other things; and obtain customer approval.
* Be sure the customer representative youre working with has adequate experience, is given sufficient responsibility and authority to gather information from all the customers departments, and can arrive at decisions that will be honored by the customer.
* Complete the front-end engineering before any detail engineering is done.
* Do a thorough, formal review of the front-end engineering phase using an outside facilitator to be sure it is complete.
* Aggressively avoid changes after the design freeze unless the design creates an unsafe condition or just won't operate. Other potential changes should be delayed and installed after the project is complete if they are important enough. (The intent is not to stifle innovation by discouraging changes, but to get those changes made during the front-end engineering part of the project.)
* Carefully estimate the cost of any changes that have to be made after the design freeze. (The cost and schedule impact of changes is almost always much more than anticipated.)
10. Lack of Lead Engineers' Interest in People
Lead engineers are often uninterested in management, leadership, teamwork, and communications. They may not consider process control engineers part of the team in multidiscipline projects, or there may be no one leading the planning and execution of the process control project (or the process control part of a multidiscipline project). Too often, process control engineers just want to be left alone to do their own thing. You should:
* Make knowledge of project management concepts and willingness to do those tasks on projects a requirement for being a lead engineer--even on projects with just one engineer.
* Hold formal, structured reviews at key points in the project to check that the project is being controlled, the methodologies are being followed, and the deliverables in the preceding phases have been accomplished. These meetings must use a facilitator outside the project to be fully effective. A good review also has significant educational value.
* Assign the customers lead person and the project manager clearly defined responsibilities to give adequate oversight/supervision to the project.
Process control projects and the process control part of multidiscipline projects face a number of challenges: they are often difficult technically, hard to manage, and face unrealistic performance expectations. Customers often give detailed input into how things are done, but they may not appreciate the effort required or understand the importance of following a work process, particularly with respect to the design freeze.
Lead process control engineers are often not managing the project. They need to become educated on modern project management techniques and the extensions needed for process control. They must act like project managers, at least for the project management tasks that need to be done on projects.
Performing organizations should adopt a standard project methodology or develop one specifically for their organization. They should train lead process control engineers on the methodology and on project management tasks. They must ensure that each lead process control engineer accepts that he/she must do project management tasks, not just provide technical leadership to the project. Performing organizations should assign a project sponsor for each project, and give him or her well-defined responsibilities. They should hold reviews at key points in the project using an outside facilitator, and always maintain customer focus. And focus on the customer.
Customers should use providers that demonstrate they have and are following a detailed, effective project methodology. Customers must support the methodology, particularly the design freeze concept. Finally, they must ensure that their project representative has sufficient experience and is given adequate authority.
1. A Guide to the Project Management Body of Knowledge, 2000, Project Management Institute, www.pmi.org
2. Trevathan, Vernon, Course MT-10, "Planning, Justifying, and Executing Instrumentation, Systems, and Automation Projects," 2002, ISA, www.isa.org
Vernon L. Trevathan, PE, PMP, has worked in process control and project management for 40 years, mostly with Monsanto, in engineering and manufacturing management positions. He is an ISA Fellow, currently consults and teaches in project management for control, and may be reached email@example.com.
Project Management Skills and Tasks
There are three main categories of non-technical tasks necessary to lead a project:
* General Management: communications, leadership, team building, motivation, problem-solving, and many other areas. These tend to be similar for all types of projects.
* Project Management Processes: general analytical project management skills as covered in A Guide to the Project Management Body of Knowledge (PMBoK), such as earned value, risk management, and work breakdown structure concept. Some of these need to be tailored to process control projects.
* Project Lifecycle: phases of the project. This is not covered in general project management literature because it needs to be different for each type of project. Many of the extensions needed for process control projects fall into this category.
PMP Certification: A Model for Control?
Project Management Professional (PMP) certification has been enormously successful and has become a key measure of a project manager's capability for job placement and advancement. It has brought more stature to the profession, which is important because most project managers (like most process control engineers) have graduated in some other field.
Certification has raised the educational level of project managers. The PMP requirements include initial and ongoing formal training, and many applicants report studying hundreds of additional hours for the exam. A side benefit has been the explosion of training courses and materials for project management.
Process control could achieve similar benefits from a certification program with real penetration. The certification would have to be standalone and not part of the U.S. Professional Engineer registration, which is not required for most controls work. Of course, because of the breadth of the controls field, an "Industrial Automaton Professional" certification program would need to include specialization in a half-dozen or so areas.