Embracing MACs: A better way of executing automation projects
Historically, automation projects have been executed as single-transaction projects. Often, individual projects, along with phases within a given project, are bid with the potential for new vendors and different engineering teams.
Historically, automation projects have been executed as single-transaction projects. Often, individual projects, along with phases within a given project, are bid with the potential for new vendors and different engineering teams. When the in-house automation teams of owner companies had abundant resources, they were able to participate in, and manage, these projects to bring consistency and standardization, and leverage lessons learned from previous projects. The landscape changed when end-user organizations streamlined staffing. While the historical execution model continued, significant issues became evident, including:
- The impracticality of in-house staff managing and executing these projects while still performing their many other job responsibilities
- Project implementation methodologies and execution philosophies varied among vendors, integrators and engineering companies, which drove inconsistency
- The constant churn of project teams surrendered the ability to incorporate adaptive learning into subsequent projects, meaning the same execution problems repeatedly plagued projects.
For some organizations, the response to these issues has been the main automation contractor (MAC) model. However, are all MACs the same? How do end-user organizations implement MACs for the greatest benefit? This article explores the value of MACs, how to implement MACs for optimal success, and why independent MACs often provide a distinct advantage.
Common end user automation project needs
Anyone who has been in the automation industry for a substantial length of time knows that each client and every project have unique considerations. However, many common core priorities span the breadth of automation projects. For example, safe project design and execution are critical. Is there a greater chance of safety incidents when projects are planned and managed by resources familiar with company standards and facility specifics, or when projects are driven by different teams each time? The intuitive answer is that familiarity is a risk reducer. What are some other core automation project needs?
- Low total cost of ownership (TCO). Reasonable project costs are a necessity. This begins with accurate cost estimating during the planning stages of automation projects. However, TCO should not always be viewed solely on an individual project basis, but rather in a more comprehensive manner. Consider a scenario where three control system migration projects must be completed at a chemical plant. If the engineering company and vendor for each project are selected based on individual, lowest-perceived TCO bids, the potential outcome is for three different companies and three different vendors to be awarded the projects. While the per project cost might seem the lowest, the overall TCO across the three projects is unlikely to be as low as it would if the project utilized the same resources across projects and maximized similarities. For example, training costs will be higher, and it is unlikely that implementation practices will be consistent, resulting in higher overall total lifecycle cost, particularly in ongoing engineering and maintenance.
- Optimized technical solution. Every automation project seeks the optimum technical solution. The question is whether the optimized technical solution for an individual project is the best overall solution. For example, if a project installs a distributed control system (DCS) controller with a capacity of 250 I/O because that is what is required for an individual project, then that may be ideal based on the single project need. However, if a subsequent project will be implemented that requires an additional 150 I/O, then purchasing a 500-point-capacity controller upfront might be a better overall option. If the truly optimized technical solution is to be realized, the overall project slate should be considered, rather than viewing individual projects in isolation.
- Schedule sensitivity. Many automation projects are schedule driven, particularly with regard to control system migrations, safety-related implementations and regulatory compliance projects. Additionally, many automation projects require unit outages or plant shutdowns, meaning that numerous factors go into choosing completion dates, with limited flexibility for completion delays. Activity coordination and integration between various automation projects are critical to minimizing operational impact.
- Getting it right the first time. Quality execution is an essential component of a project’s success. If rework is required, it impacts both cost and schedule. It is absolutely essential that automation projects are completed correctly. If implemented improperly, they have the ability to disable plant production and cause safety or environmental incidents. Familiarity with the facility, equipment and staff can all be assets in promoting increased project success.
- Seamless integration into existing infrastructure. It is common for automation projects to be retrofits or additions to existing units. This means that new automation equipment must integrate with the existing automation infrastructure. Plant knowledge can help immensely in facilitating successful integration.
Understanding MACs and realizing the benefits
Depending on who is asked, the definition of an MAC varies greatly within the industry. Fundamentally, the concept of an MAC is an alliance service provider that manages and supports all aspects of a plant’s or company’s automation projects from concept to operation. Traditional transactional-based automation projects are executed individually, with dispersed teams, as shown in FIG. 1.
FIG. 1. Typical engineering, procurement and construction (EPC) project model.
This approach often leaves projects to be executed in silos without sharing information or best practices. This model tends to increase individual project cost, and promotes inconsistencies across projects. MAC models move automation jobs from transactional-based individual projects to alliance-based automation programs. FIG. 2 shows a common integrated MAC model.
FIG. 2. Common integrated MAC project execution model.
MAC providers are typically involved in most, if not all, automation projects at a company or a particular facility for a multi-year period. The involvement of the MAC can vary based on the implementation model, and often includes some aspects of front-end engineering, standards oversight, program/project management and quality assurance. MAC provider responsibilities often extend into project execution, testing and commissioning, as well.
While many automation projects are control system focused, it is critical to recognize that other aspects to these projects exist (FIG. 3). The integration of these aspects into a comprehensive automation solution is often the tipping point for success or failure. The critical nature of this process is why it is important to select an MAC alliance partner with comprehensive knowledge of automation solutions.
FIG. 3. Primary components of automation projects.
The early involvement of an MAC across the automation project spectrum typically improves project-planning efforts, and enhances execution consistency across multiple automation projects. However, other benefits to MAC alliance relationships include:
- Lower overall TCO
- Reduced project risks
- Incorporated project lessons for adaptive learning
- Identification and maintenance of best practices
- Improved lifecycle planning for automation systems
- Enhanced automation program management
- Optimized staffing and scheduling across automation projects.
Many elements contribute to deciding what responsibilities should fall under the MAC provider. Some of these factors are identified in TABLE 1. One of the first steps in building a well-defined MAC program is to identify the various aspects of the automation programs and define a responsibility matrix outlining job responsibilities for each person. TABLE 2 shows a blended team example. Early in the MAC definition process, it is important to identify who is responsible for which aspects of the automation scope.
Choosing the right MAC partner
One of the most important decisions owner companies make about MACs is who to use as their alliance partner. There are three common options:
- Control system vendors
- EPC firms
- System integrators.
Each of these choices has advantages and disadvantages. The scope of automation work is a major driver in choosing the right partner. For example, if the project involves substantial safety instrumented system work and the integration of process analyzers, would a DCS vendor be the best choice?
Many end users are drawn to control system vendors as MAC partners because they believe that the vendors are typically the most knowledgeable on their system. This idea may be true in a purely technical product sense for the control system, but is not always the case in a project sense. Most automation projects are not just about the control system. Some of the highest risk areas for automation projects are with the setup and integration of third-party systems and software. Many control system vendors have limited experience in the system integration aspect of automation projects, or are not as in-depth in instrumentation and engineering design. If those are important scope components, then the control system vendor may not be the preferable MAC partner.
Another project element to consider is whether there are one or several control system vendor options. If writing specifications and developing standards are part of the early MAC process, before control system vendor selection, then it does not make sense to have a vendor perform these tasks. If executed by a vendor, the documents will be skewed in favor of that vendor, which will render them ineffective for bid purposes.
In a similar scenario, if the MAC is for multiple sites that do not all share the same control system, then how is a control system vendor going to bring consistency to execution on another vendor’s system? Finally, linking projects with control system vendors at the start of the project can limit hardware pricing discounts and result in a higher TCO. Competitively bidding control system hardware usually results in a more aggressive corporate discount structure and an improvement in overall project costs. In these situations, the value in using a vendor-neutral, independent MAC provider over a control system vendor is inherent.
Independent or vendor-neutral MACs have the benefit of being more objective, as they have no hardware revenue at stake. Good vendor-neutral MAC providers should look to incorporate the control system vendor into the team in the many areas where it is advantageous to do so. Truly independent MAC partners are not scope hogs, but are an extension of the owner looking to put together the best combination of resources for the project team.
System integrators and EPC firms are the two options for independent or vendor-neutral MACs. Independent MACs should have a significant history in all key systems that comprise most automation projects, such as DCS, PLC/HMI, SIS, historian, analyzers, instrumentation, etc. An additional advantage of independent MACs is that their team is usually knowledgeable in most common vendor platforms, which means that they have the expertise to span across multiple systems, if necessary.
A lack of defined work processes and project management sometimes challenges system integrators. These key aspects of successful MACs should not be undervalued.
EPC companies can be particularly appealing when projects contain heavy engineering and construction aspects. Some EPC companies do not have a true automation division, and view instrumentation and engineering as a department within their multi-discipline group. In this case, their detailed knowledge of the very specialized automation field is typically limited, and their bench depth of expert resources can be poor. These deficiencies can lead to rework at the most critical time. Understanding how to measure, track and review automation deliverables is a key area of expertise that owners should look for in selecting a partner.
The ideal MAC partner is an EPC firm with a dedicated automation division. Owner organizations get the full design capabilities of an engineering and construction company, but with the specialized expertise of a system integrator. Defined work processes and project management capabilities are typical assets that EPC firms can bring to an MAC.
Ultimately, owner organizations should clearly define key evaluation criteria and select an MAC alliance partner that best meets their specific needs.
MAC best practices
Program management is as important to MAC success as project execution details. Some key tools are needed to track and measure performance during automation project execution. These tools help ensure productivity targets are being met, and minimize risk of schedule slippage.
MAC solution providers should have the capabilities to offer the following:
- Front-end loading (FEL) stage gate execution capabilities to refine estimates and scopes (FIG. 4)
- A thorough automation-centric FEL deliverables list
- Manpower loaded schedules
- Earned value tracking and reporting, particularly on key software configuration items such as points, graphics and logic
- Comprehensive schedules integrating all aspects of EPC across all relevant automation projects
- A clearly defined cutover strategy with a detailed cutover plan
- A roles and responsibilities document.
FIG. 4. Example of a stage gate process in a MAC plan.
Key attributes that owners should look for in a potential MAC partner include EPC turnkey project knowledge, strong project management and multi-platform expertise. The company should also be a full-service automation provider and have an operations mindset.
Many owner organizations have recognized the value of MAC-alliance models in light of reduced in-house staffing. The benefits of consistent execution utilizing best practices leveraged across automation projects can lower TCO, reduce risks and enhance system lifecycle management. Keys to success include clearly defining MAC responsibilities and establishing metrics at the start of the project. Next, end users should evaluate MAC options and choose an MAC provider with a well-developed MAC model that delivers unbiased decision-making and low-risk, optimized execution of automation projects. HP
From the Archive