Get the latest updates on the Coronavirus impact on engineers.Click Here
Automation, Controls

How to find success on a process automation building project

Large-scale process automation projects have unique requirements and complexities that automation specialists should consider to mitigate issues and provide a path for success

By David Ubert and Francisco Alcala April 23, 2020
Table 1: This illustrates a project-scale matrix characterization. The model correlates characterization factors including the input/output volume, the number of controllers and staffing demands for the task of programming and integration. Courtesy: CDM Smith

Learning objectives

  • Define the framework that constitutes a large-scale automation project for process, manufacturing and building automation.
  • Identify challenges — such as project definition and client expectations, complexities and contingencies — that affect the course of a large project.
  • Review options that will mitigate issues and provide a path for success.

A large-scale process automation building project has a significant potential to fail because of its size and complexity. Large-scale building projects and megaprojects demand a high degree of communication and teamwork between all contributing disciplines in its execution, which can include process mechanical, electrical, architecture, project management, etc.

There is a lot of documentation from the Project Management Institute and other research organizations that define large-scale projects as projects with specific time frames, budgets and team sizes. However, within the automation discipline, projects have additional dimensions and capacities that can be modified to contribute to the success of a project.

Defining the framework

Several articles have been written that characterize projects according to different dimensions, however, there is no consensus on what constitutes a large-scale project. For example, the article “One size does not fit all: choosing the right project approach” states that a large-scale project has a budget of more than $500,000. Other authors define large-scale projects to have a budget between $100 million and several billion dollars.

Automation project costs are typically estimated based on the number of input and output signals. The number of staff required for the integration tasks — which may include application development for programmable logic controllers, distributed controller systems or supervisory control and data acquisition systems — is generally related to the system architecture and the number of automated processes.

Instrumentation and control projects involving the construction of new automation systems require a different execution approach and have different complexities than projects with scope limited to existing facility upgrades. The constructability approach when upgrading existing facilities is more challenging in plants with many legacy components, such as controllers, remote I/Os and machine cells because they are not typically fully documented, which can result in issues during both design and construction.

The I/O density impacts the amount of field work required and is correlated with the amount of data that needs to be integrated at the SCADA level. The scalability of the controller and the data acquisition software relate to the number of processes and machines to be automated, not necessarily to the amount of system I/O. The resources required for automation depends on the complexity of the project and system architecture rather than the I/O density.

Typically, two resources are assigned to both the PLC programming and the SCADA integration for a plantwide automation project with up to 2,000 I/O points in centralized SCADA and PLC systems because the effort of one resource is typically not sufficient to meet schedules. Additionally, it provides backup and redundancy/overlapping of resources.

For the purposes of this article, we define a large-scale project in accordance with the Burgan and Burgan project matrix modelThis model correlates characterization factors including the I/O volume, the number of controllers and staffing demands for programming and integration (see Table 1).

Table 1: This illustrates a project-scale matrix characterization. The model correlates characterization factors including the input/output volume, the number of controllers and staffing demands for the task of programming and integration. Courtesy: CDM Smith

Table 1: This illustrates a project-scale matrix characterization. The model correlates characterization factors including the input/output volume, the number of controllers and staffing demands for the task of programming and integration. Courtesy: CDM Smith

Challenges with design and construction of large-scale projects

There are many different challenges engineers face when designing and constructing large-scale projects. A few of the most critical challenges are:

Teamwork — Large-scale projects require significant communication and collaboration between all contributing disciplines to ensure successful execution, which can include process mechanical, electrical, architecture and project management. Due to the infrequency of these types of projects and the necessity of risk management, joint ventures are often organized for risk balance. Joint ventures can potentially bring together organizations that have few experiences working together and force team members to make alliances toward a common goal.

Many times project management and quality control processes are either not standardized between these organizations, are created without validation or are not completely adhered to by all team members. This scenario could affect multiple stakeholders with conflicting interests and could be reflected in different interpretations of project scopes, contingency estimation, forecasting and execution styles. These factors may cause overbudgets, underperformances and delays.

Awareness of these particularities for large-scale projects requires insightful planning and a communication program to reduce project uncertainty and risk. The development of a team with capacity, experience, adaptability and resources is one of the first challenges to confront on a project of any scale, but has a significant impact on large-scale projects.

Project definition and meeting client expectations — Poor project definition is one of the lead factors of project failure. A clear contribution of all disciplines (automation, electrical, structural, etc.) in the project schedule, task relationships, task responsibilities, deliverables, project conditions, limitations and expectations is necessary for the overall success of large-scale projects. Some research suggests that all project execution delays can be correlated to the number of process steps that were not completely vetted by all disciplines, including automation and the unclear designation on task responsibilities.

The client is the primary source of the project scope. The alignment of client expectations with definitions of deliverables, tests and project results has an essential role in the project definition. When clients cannot clearly describe their needs at project conceptualization and constant changes are requested during project execution, the consequence is that project tasks and deliverables regularly change as clients and team leaders realize additional requirements across the design phase.

Complexities — Most automation projects characteristically fall into one of these three categories:

  • Providing the automation component for new facilities or facility expansion.
  • Providing the automation component for upgrade or rehabilitation for existing facilities.
  • Providing services for optimization and high-level integration projects.

Automation projects regularly are defined by the amount of I/O, controller, system architecture and level of complexity; however, the complexity aspect plays an essential role during the planning, leadership definition and project execution.

Complexity is the second dimension used to classify projects. A full understanding of the complexity factors from the automation perspective may provide crucial insight to identify the skill set required of the management team to provide value leading the project to execution.

The elements of complexity for automation projects do not depend entirely on the state-of-the-art technology and execution factors. Contract strategy, stakeholder engagement and team conformation also play an essential role in how complexity is defined. Senior project managers are required to have constant oversight of the complete set of existing procedures for high-complexity megaprojects. Low- to moderate-complexity projects can be handled by junior project managers with less experience.

From the automation perspective, the relationship between I/O count and complexity can be circumscribed to the matrix shown in Figure 1. This matrix can help clarify the leadership profile that may be required for each scenario.

Figure 1: From the automation perspective, the relationship between input/output count and complexity can be circumscribed to the matrix. Courtesy: CDM Smith

Figure 1: From the automation perspective, the relationship between input/output count and complexity can be circumscribed to the matrix. Courtesy: CDM Smith

High-complexity projects with low I/O count regularly fall within the research and development field, including first-of-its-kind project and pilot plants, which require team leaders with detailed knowledge of the problem/process intended to be solved or automated, in addition to in-depth knowledge of the state-of-the-art technology used and skills in data analysis.

Complex projects with many I/O, such as refineries that can have up to a 24,000 I/O count, may include a large amount of control loop, high-level integration across business units, implementation of optimization applications and a safety component.

Automation projects with a high number of I/Os and low complexity, i.e., plantwide telemetry upgrades for water distribution or water collection, typically demand team leadership with field execution skills and experience with standardized automation infrastructure.

Contingencies The team in charge of project execution increases efficiency by identifying and analyzing known risk factors across all phases of the project. In general, the uniqueness of many large-scale projects makes the use of statistical methods and simulations a poor method for identifying potential risks during project execution.

Risk identification is a critical skill to help reduce contingencies. A contingency is the realization of known and unknown risks. Project management that does not include policies or procedures to deal with contingencies has the potential to become a liability for large-scale projects.

Understanding the contingency of a project is essential to select an appropriate method of risk management. It is also essential for involving the necessary people and organizations to effectively deal with each specific contingency situation. This requires a team of resources with experience related to the specific components of the project. These contingencies must be identified early and monitored throughout the duration of the project or until they have been overcome.

The three main dimensions of a contingency during project execution are the detection time frame related to the project schedule, the impact on cost and schedule and the overall complexity of the issue.

The conformation of a risk and contingency team with methods and procedures may result in a valuable tool to mitigate the effect of the project eventualities. The contingency team, with methods and procedures, should be prepared to evaluate the contingencies in terms of time, complexity and impacts in terms of project schedule and cost and provide the course of action toward the issue’s mitigation. The timeline dimension defines how late or early the eventuality occurred on the project schedule (early, mid or late the project time frame). The performance impact shall be determined by the project manager in terms of schedule, cost and quality (see Figure 2).

Figure 2: Contingency model and action plan: The performance impact shall be determined by the project manager in terms of schedule, cost and quality. Courtesy: CDM Smith

Figure 2: Contingency model and action plan: The performance impact shall be determined by the project manager in terms of schedule, cost and quality. Courtesy: CDM Smith

The automation discipline is affected by contingencies as are most of the other disciplines that contribute to a large-scale project during execution; however, the events that are known to have the most impact on automation discipline are:

  • Changes in project requirements: This is one of the most frequent contingencies and has a significant impact on project performance. Flexible design and standardized integration and programming method may help to mitigate the impact.
  • Communication issues: This typically has a mild impact on project performance, but if not addressed in the early phase of the project execution, it has the potential to produce a cascade effect and distress the morale of the team with unexpected results.
  • Technical difficulties: This impact is directly correlated to problem complexity, which affects its influence on project performance. Recommended mitigations:
    • Design simplification and technology validation.
    • Develop and enforce completed test procedures.
    • Contract a Tier 4 vendor technical support. A Tier 4 support is the highest level of the multitiered technical support services that a vendor can provide. This is commonly used in the information technology and operational technology industry. Technical support is often subdivided into four tiers, or levels, to better serve a business or customer base. Tier 4 or Level 4 services support is generally provided for hardware or software vendors. A Tier 4 support is commonly part of the service level agreement and may include specific services provisions that include response time event tracking, escalation, etc.
  • Technology changes: This contingency is frequent on projects with extended design and bid phases. Its impact on project performance is typically minor. When detected in the early phase of the project, its impact can be resolved with changes or exceptions on the original design.
  • Lost or changing team members: This contingency has been documented to occur on 38% of large-scale projects and affect the project performance of 60% of large-scale projects. For the automation discipline, this contingency has a significant impact when occurring during the commissioning and startup phase. It can be mitigated with simplified design, effective changes in tracking enforcement and standardized programming procedures.
  • Issues with untested automation components: This contingency is the most frequent source of schedule slips that affects the commissioning and startup phases, mainly when dealing with different vendor technologies. Any automation component that is not tested becomes a potential contingency.

Success factors

Experienced automation leaders have the capacity to provide action and guidance for risk assessment and contingency mitigation. Some of the critical factors that have the potential to provide a path to success are:

  • Before beginning any large-scale project, perform active research, internal to the current organization and others in similar industries, to identify best practices and lessons learned from similar project experiences. Failing to perform a review of past lessons learned sessions with the project team causes leadership to miss opportunities to implement proper processes and practices to complete the challenge successfully. This exercise may lead to gathering useful information that can be incorporated as checkpoints into the new project plan.
  • Conform a project team with proven experience in similar projects or that have participated as a member of a large-scale project to have an advantage with their collective experience.
  • Define an effective communication mechanism that propagates decisions and changes made at any level to the right team members to avoid oversaturation of information and help to separate the noise from the signal.
  • Organize a leadership structure proactively and continuously throughout the project to facilitate the early recognition of undesirable events.
  • Incorporate a risk and contingency team with the most experienced members of each discipline and provide resources and capacitation for risk and contingency assessment. Some studies reveal that 50% of the contingencies were not anticipated before causing significant performance issues on cost, schedule and producing a cascade effect. Automation leaders must be capable of reviewing the project scope at the early project stages, not only with the intention of producing a cost estimation and work break structure, but also to raise flags and recommend the best course of action before the contingencies impact any project performance factors.
  • Include Tier 4 support in the budget and develop a robust technical validation of the technology to confirm technology compatibility and performance.
  • Participate actively and proactively in all workshops and systematically cover all automation components when interacting with the client to understand their expectations and understanding of the project scopes to develop adequate deliverables.
  • During the design review, evaluate automation components and tasks with the goal to reduce work complexity. Exploring critical aspects that can help to simplify the scope, deliverables and work process minimizes the potential for problems and contingencies to make the project more manageable. Standardization is the most common mechanism of work simplification; this may include drawing production, bulk engineering tools and the use of standard programming libraries.
  • Develop and implement version control tools and standard operating procedures from the beginning of the integration activities. Documentation of all programming changes shall be enforced for all programming team members.
  • Develop and enforce completed and detailed test procedures with clear acceptance criteria that apply for each validation, including all automation components. Avoid oversimplification of test procedures limited to I/O testing and human machine interface
  • Ensure that the client participates in most of the test procedures.
  • Design a factory test procedure to validate the program sequence and HMI application with the control narrative that includes all hardware and software components. Coordinate factory tests when possible, executing a full integration validation with the vendor system.
  • Design a factory test procedure to validate program sequence and HMI application with the control narrative simulating all possible scenarios. Design a testing procedure that verifies all interconnected systems, logic and fail conditions.

David Ubert and Francisco Alcala
Author Bio: David Ubert is an automation technical strategy leader at CDM Smith; Francisco Alcala is an automation engineer at CDM Smith.