The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is Tip #31, and was written by Hunter.
As a project manager I am responsible for a myriad of activities, but if I consider them in aggregate I realize that they are just different manifestations of the same thing: my job as a project manager is to recognize risk and manage it.
Concept: Successful project managers are masters at evaluating, mitigating, and avoiding risk. Their job is to bring a project in on time and within budget. Anything that can jeopardize that is a threat and must be avoided.
Details: The best project managers recognize problems BEFORE they are problems and either find ways to avoid them or have contingency plans in place to effortlessly address issues as they occur. They must maintain a vigilant guard against problems (or potential problems) and mentally have a Plan B (or Plan C or even Plan D) available to immediately bring to bear if necessary. Jiminy Cricket makes very poor project plans – wishing upon a star and hoping that things work out is NOT the way to run a project. During the project, continuously monitor how things are going against the plan and adjust quickly as necessary. If a manager acts when the project is a third of the way through, then he or she has time to catch up and still make the budget and/or schedule. If the manager delays taking mitigating action until the project is 80% or 90% complete, then failure is virtually assured.
Here are some potential sources of risk and ways to eliminate them:
• Choose the project team wisely. If at all possible, try to keep the same core team and only add a new member on occasion. A core team knows each other’s strengths, weaknesses, and quirks and can communicate at a much higher level with very little effort. They also can bring to bear a strong history of techniques from past projects and lessons learned.
• Know the technology. If the team is new to a DCS or network technology, try to work some smaller projects and gain some experience before jumping into a larger project.
• Know the process and/or the client. Understanding the process and the client’s needs is critical for project success. If the process is untested or the client is new to the team, budget more time to get to know the client and understand his needs.
• Send graphics or partially completed software to the client for early review. If possible, develop a graphic and all of the underlying modules (with imbedded simulation) as a unit and forward it to the client for review upon completion. If there is a disconnect between the client’s expectations and the team’s work product, the team needs to know that early!
• Build and test the control panels in advance. (This was discussed previously in Tip #29.)
• Avoid the latest version of software. If the project does not require the latest functionality, do not rush to utilize the latest software release. With increasing frequency, vendors are releasing poorly tested software and letting their customers debug it for them. Let someone else fight that battle.
Watch-Outs: Order any project material early and constantly check on its progress once ordered. Many projects have been delayed because the equipment failed to arrive on time. Sometimes the purchase order never got placed by the purchasing department, sometimes the vendor lost the order, and sometimes the factory got behind and failed to deliver or delivered the wrong thing. Assign a person to check up on each purchase order and when items arrive, open the boxes and make certain the material is correct.
Exceptions: There really are not any exceptions for risk management. EVERYTHING can be a source of risk and should be monitored. A subcontractor can have a long track record of success but fail to deliver on time due to internal organizational changes or workload. Valued vendors may have manufacturing problems and the usual two week delivery may extend to 12 weeks. Take nothing for granted.
Insight: If the project involves programming a safety interlock PLC consider staying at LEAST one major revision behind and if that revision was short lived or had problems, it may even be worth staying TWO revisions behind. When dealing with safety interlocks, the programming is rarely complex and system stability is far more important than getting the latest bells and whistles (and the bugs often associated with them).
Rule of Thumb: As a project manager, continuously monitor everything for signs of problems and immediately inquire if something seems amiss. No project manager wants to be surprised.
About the Author
Gregory K. McMillan, CAP, is a retired Senior Fellow from Solutia/Monsanto where he worked in engineering technology on process control improvement. Greg was also an affiliate professor for Washington University in Saint Louis. Greg is an ISA Fellow and received the ISA Kermit Fischer Environmental Award for pH control in 1991, the Control magazine Engineer of the Year award for the process industry in 1994, was inducted into the Control magazine Process Automation Hall of Fame in 2001, was honored by InTech magazine in 2003 as one of the most influential innovators in automation, and received the ISA Life Achievement Award in 2010. Greg is the author of numerous books on process control, including Advances in Reactor Measurement and Control and Essentials of Modern Measurements and Final Elements in the Process Industry. Greg has been the monthly "Control Talk" columnist for Control magazine since 2002. Presently, Greg is a part time modeling and control consultant in Technology for Process Simulation for Emerson Automation Solutions specializing in the use of the virtual plant for exploring new opportunities. He spends most of his time writing, teaching and leading the ISA Mentor Program he founded in 2011.
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Hunter has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.