Reflecting on my long career as a project manager, I have come to realize process automation projects have unique challenges, which make them more difficult to execute than other types of projects. Why is that? Based on my experience and many discussions with peers, here are some key reasons:

Complexity

The process automation industry is highly fragmented with numerous global suppliers each controlling a small portion of the market. With the typical automation project containing literally thousands of individual components, every automation system ends up as a mixture of parts from multiple suppliers. Because these suppliers have limited expertise outside of their immediate product family, the project team is left to integrate all these parts. Considerable engineering and coordination is required to ensure this plethora of equipment comes together to form an integrated, high-performing control system. The resulting designs are highly engineered and customized for each application.

Adding to the challenge is that automation components are based on rapidly changing computer, software, and electronics technology. Unlike other disciplines, automation knowledge becomes outdated every few years as the underlying technology advances. Not only is it difficult for manufacturing facilities to keep their installed systems current, project teams need to be proficient in implementing the latest technology. Ongoing effort is required to keep technical resources updated to ensure sound decisions are being made, and the team members can effectively execute the work needed.

Third-party interfaces to various subsystems often require special skills and knowledge, as standardization for data communication and formatting has been lacking among suppliers. Third-party interface data is not only difficult to transmit through various specialized protocols but also is usually the last thing the supplier delivers-delaying configuration development and testing until the subsystems arrive at the job site.

The inherent complexity of automation requires extensive documentation to define the requirements and maintain the resulting assets. The documentation is also very interdependent. A simple change can affect multiple documents. Something as simple as changing an instrument tag affects the piping and instrumentation drawing, I/O list, instrument specification sheet, distributed control system (DCS) database, field junction box drawing, marshalling cabinet drawing, and loop sheet. As a result, documentation is difficult to keep current and accurate throughout the project.

Scope evolution

Unlike most other types of projects, automation scope evolves throughout the life cycle of the project-even through commissioning and startup. Expecting to completely define the scope up front with little or no change is an exercise in frustration. This is where project organizations focused primarily on civil- and mechanical-type projects often stumble, because they fail to make allowances for this characteristic.

Design inputs for automation scope come in piecemeal throughout the project as the various project stakeholders perform their detailed engineering. Key information regarding the automation details for various packaged equipment modules (skid packages) are not known until deep into project execution after those suppliers are selected and perform their engineering work. Some operations requirements are only revealed when the operators have a chance to put their hands on the system during testing and commissioning.

There is often a significant gap between the process control requirements as set by process engineering and the definition needed to create the actual system configuration. This is because the process engineers do not speak the configuration engineers' language. Translating the process engineer's control requirements into the format of the configuration functional specification is required. In addition to requiring an understanding of the underlying process, this translation is a highly specialized task requiring resources with deep configuration expertise on the control platforms. A similar translation is required of mechanical, civil, and electrical disciplines as well. Any errors or omissions in the resulting functional specifications cause changes down the line.

Schedule constraints

The automation scope has numerous dependencies on other disciplines involved in the project. These other disciplines are not able to finalize and communicate the automation requirements until they perform their own engineering tasks. For example, before instrumentation and control valves can be specified, process engineering needs to define the process conditions and control requirements, and mechanical engineering needs to define line sizes, materials of construction, and any physical installation constraints.

These dependencies often cause late changes and schedule compression of the automation engineering effort. Having to absorb all the changes while being expected to hold to the original timeline and budget is frustrating and can lead to skipping steps for the sake of meeting expectations. The discipline to properly execute the required engineering while meeting the project schedule and budget requirements is a delicate balance.

Automation is always on the critical path for completion. No matter how large the overall project, there is always a task near the end to test and commission the automation system before startup. This can only be done after all construction is completed to keep from violating the integrity of the tested system. When the overall project is late, there is additional pressure to minimize or shortcut commissioning activities, which can have negative consequences if not properly executed.

The situation can be even worse in the case of brownfield projects. Most manufacturing facilities are under pressure to minimize unit downtime to lessen the impact on production. Without widespread recognition for the importance of thorough automation system testing and commissioning, it is difficult and stressful to maintain proper checkout discipline when everyone else is pushing to achieve an earlier startup.

The human element

The automation system is the primary interface between the collection of equipment that makes up a plant and the operator who is trying to run it. To achieve successful operation, it is critical for operators to get an accurate and complete view of how the process is behaving and how the equipment is working. If the automation system is contributing to process upsets or not clearly communicating an accurate picture of unit operation, the ongoing lost opportunity costs can be massive.

Although there has been excellent human-factors science applied to this human-machine interface (HMI) in recent years, there is still a large amount of personal preference that must be accounted for. Because the automation system is such a tangible element with a look and feel that anyone can understand, it seems everyone has an opinion about how it should work. Operators have inherent perspectives and biases based on past experience with other automation systems, but they may not all be applicable in the current scenario. These personal preferences are difficult to completely define but need to be accommodated or corrected to make the interface fully effective and achieve operator buy-in.

Changing an automation system is easy-simply a matter of programming. However, this ease of change makes it difficult to manage, because it encourages ongoing tinkering with the configuration. Robust change management procedures are needed, including an approval process to ensure each change is justified.

There is also a creative element to contend with. Modern automation systems allow significant flexibility in how various functions are programmed in both controller configuration and the HMI. Although this flexibility enables the automation system to be customized to optimally control the process, it also makes requirements difficult to completely define and enforce.

The road to success

How can you mitigate these numerous challenges inherent in automation projects? Respecting what makes them unique is a good start. Engaging an automation service provider with experience and expertise to handle the challenges is essential. Beyond these basics, here are some additional suggestions:

• Early engagement of automation engineering in the front-end loading (FEL)/front-end engineering design (FEED) stages results in clearer definition of the project scope and decreases the risk of rework in detailed design.
• Reduce customization of the design by using standard configuration, graphic, and documentation templates to decrease the amount of work required to execute the automation scope.
• Apply robust project management discipline, like you should on any large, complex project. A detailed project execution plan, schedule, and quality plan are all important for effective execution. A well-developed roles-and-responsibilities matrix helps to define exactly what information is expected from each stakeholder. A risk register can identify potential problems and associated mitigation plans before issues surface.
• Technologies and processes can minimize the impact of late delivery of design inputs. For example, auto-generating documentation based on the I/O database can quickly create and update key deliverables.
• A vigorous quality assurance program can help mitigate the subjective nature of automation requirements.
• Flexible system architectures, like configurable I/O modules, can help to minimize the impact of late changes on testing and documentation.
• Appointing an interface manager to the project team can reduce the risk resulting from multiple dependencies on other stakeholders. This is a position dedicated to facilitating information flow from the various disciplines and equipment suppliers.
• Disciplined testing and commissioning procedures executed by qualified resources are critical for safe and efficient startup. Shortcuts here inevitably lead to ongoing operational problems, costing many times the minimal savings from reduced commissioning time.

Process automation projects are difficult to manage. The inherent complexity, evolving scope, schedule constraints, and human interaction all contribute unique challenges. Utilizing a project manager and a team with experience managing these characteristics and the ability to maintain proper execution discipline are critical to achieving success.

A version of this article also was published at InTech magazine.