Stay involved, get the most from an automation project
Legendary football coach Vince Lombardi once observed, “If you’re not keeping score, you’re just practicing.” Success requires everyone on the team to know not only what they’re doing, but how well they’re doing it. The same could be said of an industrial automation project being executed by a team of end users and system integrators. They need a plan, they need to communicate with one another, and they all need to stay in the game until the final score is tallied.
“No project will ever be successful until there is a complete recognition on the customer’s part that they must take ownership of the project,” said Frank Fontana, project manager at system integrator MicroMod Automation. “From the project’s onset there must be a defined person who is not just waiting to have a completed installation turned over to him but is active in the everyday activities of the project. This owner must also have an understanding of the schedule and milestones for the project.”
He added, “This person will also serve as your interface to the existing operations staff. In this role he is the one you will go to to ‘make things happen.’ He will be in position to provide any in-house expertise you will need. He will be the individual to go to when you need to shut down power, test fire the new system, or have something moved to gain access to a piece of equipment you must connect to. This individual must also be your contact for site documentation and safety issues. Your success must be viewed as his success by the company.”
Too much, too little
Several of the system integrators who responded to this survey agreed with Fontana, but some pointed out that involving clients in their own projects can be a challenge. “Customer involvement requires periodic meetings whether by telephone or face-to-face to ensure schedules and modifications to scope are addressed and understood by the project team,” said Ernest Smith, an engineer for Good Manufacturing Practices Inc. “This requires an investment in customer time that some do not understand is required for a successful timely project completion.”
Ronald Wensley, owner and principal engineer for Controller Tuning and Design, explains why client involvement is so important. “The customer needs to be directly involved in the project and work with the integrator every step of the way. If the end user is totally hands-off and is letting the integrator do all the work, the end result probably will not be what was needed or wanted. On the other hand, if the end user is too involved and micromanages the project, then this can be equally detrimental to the outcome of the project.”
Greg Stirling, president and CEO of Stirling Engineering, elaborated on the trade-off between too much and too little end-user involvement. “The client should have a point-of-contact project engineer who participates in the design and decision-making process, particularly if they have experience and talent in that area. The project engineer is the ambassador for the project, he sells the system to the company, and the system integrator is an extension of this resource. The project engineer needs to collect all the specifications and requirements from the personnel at their company.”
“However, it is more important that he either thoroughly understand machine design and its hardware (as well as his own process) or stay out of the way so the system integrator can do it. Pretending to have know-how or experience which is clearly not there can jeopardize the project, raise costs, and delay shipment.”
Good or bad change
Constantly changing the scope and details of the project can also jeopardize its success. At the very least, said Stirling, “system integrators don’t like strangers appearing late in a project with a new set of specifications, requirements, and additional scope expected at no extra charge.”
Worse still, some clients want to be so involved that they end up dropping the ball. “Some end customers don’t have a very good understanding why changes cost what they cost” in terms of project setbacks and the integrator’s time, said Karen Pigler, managing member of Pigler Automation. “We have worked with customers who didn’t seem to expect any negative effect from a delayed release of input over several months, multiple changes in instrumentation, and last minute changes to specification when the hardware and software is almost ready to be tested.”
But sometimes changing the game plan can be beneficial, said Don Dexter, vice president of IAS. “Integration projects have a certain amount of inherent unknowns. Customers are rarely able to fully define the features and performance of the new system in exacting detail. Oftentimes the point at which they see what the system is capable of is the time they realize new ways in which it can be utilized.”
He added, “This is natural and good. Asking them to do differently would only spend a great deal more resources up front, which would then be subject to change later. This is why it is essential for both sides to understand that it is mutually beneficial for each other to implement flexibility into their operations so that when value-adding changes are realized, they can be implemented with minimal impact on the flow of the project.” In other words, sometimes winning the game requires a new strategy.
Pigler agreed. “If there is a good, agreed-upon change management in place between customer and integrator, it may help to eliminate bad endings for otherwise successful projects. And this in the long run may change the customer’s attitude towards changes and preparedness at the beginning of a project.”
John Salls, president of Vision ICS, said he believes that every automation project should include a plan for incremental improvements to the system. “For example, a large number of the vision systems I have deployed have a capability to save both accepted and rejected images from the production line. Many of my customers will periodically review these images to determine if they have a process or product change that causes a significant false accept or false reject issue. If one is discovered, we simply make improvements to the system where possible. Many will also add in additional capabilities to inspect as important features come to light or become more important. If the proper planning for these changes were not made up front, it would become much more difficult to make these small incremental improvements.”
Get help, do it yourself
Mark Cleveland, lead engineer at Encobotics, pointed out several other opportunities for end users to stay involved with their automation projects. “In my experience, integration projects have gone most smoothly when the end user took a lot of ownership in the process and was determined to help out in every way. Aside from accurate, thorough communication, which is essential, the end user needs to be willing to send his employees to all training recommended by the integrator, not just expect the integrator to train the employees from scratch at their site.”
“The end user should also be ready to supply prints and samples of any parts to be dealt with by the integrator’s system. The quicker the end user responds, the better off the project usually is. If you dragged your feet for a month getting good parts to your integrator, don’t get upset when he’s a week late installing!”
“And the more your employees learn about the system, the better off you will be in the long run. If your maintenance crew knows how to repair the system, even if it’s under warranty, is it really worth it to lose production for a day while you wait for a service tech to come from the integrator AFTER having spent a couple hours on the phone with him explaining the issue? I think we’d all rather have a maintenance guy call up the integrator, explain the problem and how he plans to solve it, and get the approval of the integrator to make the fix himself.” Doing so can reduce downtime from a matter of days to a few hours, Cleveland claimed.
Close but not too close
He concluded that “the end user MUST realize that this is going to be his machine when all is said and done. He needs to make every effort to give the integrator what they need to make the project a success, realize that delays are common and that a rushed job is not a thorough job. He also needs to make sure his own people know all that they can know about the system. Someday, down the road, that integrator may not be able to help you, but your own people that have had experience with a machine every day most certainly can.”
On the other hand, “an end user always should maintain an arm’s-length relationship with the integrator,” said Larry Iverson, a retired project management professional, formerly with Computerized Processes Unlimited. “You shouldn’t assume that there always will be a cozy and thoroughly trusting relationship between the integrator and the client. In the final analysis, the integrator must be concerned with cost, performance, and schedule from his perspective. After all, he must realize a profit. Likewise, the end user must be concerned with cost, performance, and schedule from his perspective. Those perspectives usually are not the same; nor should they be.”
Perhaps Lombardi should have added, “Keep one eye on the ball, and one eye on your point of view.”
Learn more about each of these integrators and others at www.controleng.com/integrators.