Planning Cuts Automation Project Risk
System integrators share tips on how avoiding surprises helps them succeed. Clear communications and documentation top the list. Tools follow for project management.
Risk reduction is often cited as one of the primary benefits of hiring a system integrator for an automation project. After all, experienced practitioners in any technical discipline are generally more successful than enthusiastic amateurs, and system integrators are the subject matter experts when it comes to designing and installing industrial automation systems. But even the most talented system integrators can't make an automation system work properly without knowing what it's supposed to do.
"Identifying and recording the end user's requirements is the single largest factor in defining a project's success," says Dean Streck, chief operating officer of VI Engineering. "We tell our people who are doing project-based work every day that they must clearly define what they are going to do — in writing — before starting and also document how they are going to prove that they have met those requirements."
Brent Stromwall, vice president of Polytron agrees. "A clearly stated project and communications plan are essential to ensuring that the integrator and the client's stakeholders agree what 'success' and 'done' look like."
After all, says Jerry Armstrong, applications engineer at Walco, "there is nothing that will deflate a customer's confidence faster than an after-the-order-is-given statement such as, 'I didn't know that was part of your requirements.' The salesman or application engineer that is responsible for quoting the job must spend an adequate amount of time with the customer and the equipment to find out exactly what it is that the customer wants, and have a good idea of how how it is to be accomplished. This doesn't mean he needs to go into minute details such as the color of pushbuttons, but all major factors and the extent of the project must be defined."
Armstrong adds, "Having done our homework correctly, there will be fewer surprises when it comes to physically implementing the system."
Don Ulrich, president of Stone Technologies, agrees that making a plan and assessing the risks are key to the success of any automation project. "We tell clients up front how we're going to do the project in infinite detail. That becomes the basis for the contractual details and setting expectations. We then go through a complete risk analysis — schedule risks, technology risks, resource risks, even the risk of clients not providing the information we need in a timely manner.
"As we go through the project and have reviews, we revisit the risk question because new risks pop up that we didn't think of initially. The risks we can foresee we address aggressively. It's the risks that we assume aren't a big deal that cause us the most trouble."
Joel Langill, senior consultant and staff engineer at ENGlobal Automation, agrees. "These risks can be technology risks such as what would be involved when implementing a new system or a new release of software. Or they can be risks to the client's operations, such as how they will successfully migrate their operator stations from an older to a newer technology, and at the same time move to a consolidated control building."
He adds, "Any risks unique to the project should be documented and discussed. Once these risks are understood, specific activities should be amended to the test procedures to demonstrate success and essentially mitigate these risks before the project shifts to the field."
And when it comes to planning those tests, Langill prefers to start from the end. He develops the final testing, site commissioning and site cutover plans up front, then designs the rest of the project with those tests in mind.
"One of the most common mistakes in projects that are large, complex or that involve integration with numerous automation components is that the final tests are not developed until just before it's time to run them," Langhill notes. "This often results in a test plan that either fails to test all aspects of the automation solution or masks known problems, leaving them to be found during costly site activities."
Dan Purvis, senior systems engineer and general manager for the Houston office of Optimation, describes how his company creates their test plans from the project's design documents using the V-model diagram shown in the "Project development methodology" figure. Not surprisingly, the process starts with the end users' requirements. The three phases of the testing process follow from the three documents shown in the figure.
"On the back end of the V you get a series of items that naturally happen because the hard work of the project has already been accomplished on the front end," says Purvis. The final site acceptance test corresponds to the user requirements, the factory acceptance test corresponds to the functional requirements, and the system documentation corresponds to the design specifications. In between comes the actual implementation of the project — writing, integrating, and testing the software.
Purvis adds, "Programmers and operators manuals fall right out from the design and architecture documents in the design phase. The factory acceptance testing (FAT) happens naturally from the FRS (functional requirements specification) and FAT test documents. You run through the FAT and answer the questions. Any nonconformities create punch lists for rework, but the number of surprises is minimized."
Stone Technologies' Ulrich cites "no surprises" as Rule #1 for planning and managing a project. After all, he says, integrators can't manage what they don't know. Rule #2 is "I-can-fix-that-later does not constitute a plan." Ulrich says clients much prefer to hear that there's a problem as soon as it comes up, especially if the bad news comes with a new plan to fix the problem.
Ray Bachelor, president of system integrator Bachelor Controls, elaborates on the project management issue: "Project management is not just reporting the news. Project managers are supposed to manage the project to ensure that it remains true to the original functional requirements. They should have a realistic schedule to begin with, rather than such an optimistic schedule that slips become inevitable."
Vance VanDoren is contributing editor for Control Engineering. For a detailed example of how the V diagram might be applied to the development of a specific automation project, view this article online at www.controleng.com/archives .