19 ways your automation project can fail and how to prevent it

July 11, 2013
From failure to define requirements to disengaged project managers, changes in direction or employees who lack the skills to do the job, the sources of automation project failures are often easy to identify. Fixing them is usually the bigger challenge.
1. Not getting maintenance and operators involved from the start. Some assembly jobs have been done by hand for years. The worker who has been on the line for a long time will have seen what has and has not been done in the past. Just because components on paper are all uniform does not mean that they are in tolerance in the real world. Maintenance workers have dealt with more fixes and operator complaints than the design engineer. The key to a new piece of equipment working well is maintenance and operators taking ownership of the system. If they aren't on board, the machine may just end up being a big paperweight.

2. Lack of the right people resources. Too often a project is running at full throttle, only to come to a complete stop because the person originally tasked to do the PLC engineering or development is busy putting out fires, has Inherited another project or is otherwise not available. When developing schedules and project plans, try to gain stakeholder commitment to use contingent resources or assign another skilled resource based upon a scheduled "check" item.

3. Unengaged project managers. When the project manager is unengaged or unresponsive to requests for information or approvals, you know the project is destined for failure.

4. Lack of scope benchmarks. Without scope benchmarks in place that are tied to the proposal document, the project manager can't assess programming time for each phase to help detect scope creep. Benchmarks help deter project stakeholders from adding "capabilities" to the process that can lead to both financial and timeline strains, and ultimately to a failed project.

5. Skills mismatch. Many automation projects are viewed as successful when the system is in the development and testing stage, but it becomes an entirely different scenario when the project is implemented in the field. Errors begin to crop up. This is often due to the different skill levels of the people who develop the project compared to the people who are sent out to execute it in the field.

6. Poor planning. Most projects fail because of poor planning. There is a tendency to underestimate the complexity of the project and over-estimate the capabilities of the team. Late changes are the worst enemies of any project. The project owner also needs to establish the most important priorities for the team, such as cost, quality, maintenance, training, stocking of components, safety, etc. This will assure that decisions are aligned with the project's goals.

7. Failure to manage expectations. Make sure all stakeholders understand the trade-off between scope, budget and time frame. Communicate this deliberately, formally and frequently.

8. Design misalignment. Failure often comes from a lack of communication on the design of the project, from component selection to the format of I/O tags, networks and programming structure. Provide a scope prior to design that allows all items of the design to be agreed upon. As this document is created, members of the team or the integrator can then point out potential pitfalls, such as using multiple networks or not selecting a common controller.

9. Confusion. An insufficient amount of effort in the front-loading stage, or subsequent budget cuts or direction changes by management, will result in confusion for the project team. It's a standard recipe for failure.

10. Other reasons for failure.
Unrealistic schedules are set.Potential risks are not calculated and planned for.Engineers working on a project lack the necessary skill sets or experience.Insufficient milestones to measure progress and identify problems.Outdated / incorrect documentation in brownfield projects.Insufficient time in the schedule for third-party communications or for developing a particular section of the system.Mismatch in the requirements of the project and the solution given by the supplier.Missing of the minute details pertaining to engineering and scope of supply.Failure to establish a clear schedule to finalize process and equipment designs.Lack of training to enable plant personnel to operate and maintain complex systems and new technologies. Five points for failure.
  1. Failure to plan for and handle project resource changes.
  2. Failure to know or admit that requirements are not well defined.
  3. Failure to address requirement definition problems in a timely fashion.
  4. Failure to plan and execute design review and approval milestones.
  5. Failure to engineer the verification of project deliverables sufficiently, including lack of inspection and test planning.

Liked this article? Download the entire playbook here

Share this Article

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...

AVEVA™ System Platform: Smarter, Faster Operations for Enhanced Industrial Performance

AVEVA System Platform (formerly Wonderware) delivers a responsive, modern operations visualization framework designed to enhance performance across all devices with context-aware...