By Greg Elliott, Brillig Systems,Operations Manager - Indianapolis
and Andre Michel, Brillig Systems, Operations Manager - Canada
Project management is as much of an art as it is a science. One of my instructors once defined project management as The Art and Science of Getting Things Done. Certainly, the science of project management is becoming well-published and practiced. Organizations such as the Project Management Institute (PMI, www.pmi.org) and others have helped to drive standards and best practices for the nine knowledge areas of project management. Most industries have embraced the value that project managers bring. For example, it would be unthinkable to execute any sizable engineering and construction (E&C) project without an overall project manager. It is also my belief (and the results of many case studies prove it) that executing an automation project or the automation component of a large project without an automation project manager is as reckless as executing an E&C project without a project manager.
On a typical engineering and construction (E&C) project, the overall project manager has to manage many different disciplines and functional areas that eventually have to work together for the success of the project. Compound this multi-disciplined deliverable set with the fact that construction is always on the critical path, and it is easy to see why a project manager is extremely important to the success of the project. In very much the same way, automation teams require just as much coordination as E&C teams and are just as critical to the success of the project, except that in the case of automation, it is not buildings that are being constructed, but software and systems.
Before we move on, let’s take a moment to define a typical automation scope in the current context so that we can agree on the area of automation project management. Automation could be broken into the following areas:
- Instrumentation (Level 0) ― All activities associated with the specification, procurement and installation of instrumentation.
- Control Software (Level 1) ― All activities from design through informal testing.
- Formal Software Testing ― Testing development and execution or support of commissioning activities.
- Control Hardware (Level 1) ― All activities from specifying hardware to installing and inspecting panels.
- Manufacturing Network Integration (Level 2) ― Data historian, clients and servers.
- MES (Level 3) ― Including batch and recipe.
For regulated industries we should also include computer system validation including validation plans, CSV strategy, test plans, business continuity plans, security plans, disaster recovery plans and measurement of uncertainty.
Table 1 shows some activities that are within a typical automation project delivery. The table shows that automation project activities begin at design and continue through start-up. However, the automation project manager (APM) role typically starts at business case development or project justification and those functions are outside the scope of this discussion. Looking at the list of activities that fall under automation, it is easy to see that the scope of automation spreads across many disciplines and many layers of the manufacturing and business architecture. From the diversity arising from physical instrumentation, to the development of recipe interfaces and MES integration, automation is significant and complex. Table 1 shows some of the interfaces with the various phases of the project and examples of associated deliverables or activities. We can see that there is a potential for many interfaces and many silos of expertise on projects. It is already difficult to integrate the entire automation subcomponent, but the automation also needs to integrate with other disciplines. The integration and coordination process quickly requires the full attention of the automation leader as the project gets bigger. This complexity of the automation discipline means that it is difficult to integrate into the overall project.
In the traditional project organization, automation engineers report to the general project manager as shown in Figure 1. This creates a skill-set gap in the project resource model because the overall Project Manager does not have the requisite background in automation and as such will have difficulties interpreting the information provided by the automation engineers. The gap is produced by the failure to identify the uniqueness and complexity of automation and thus creates unrealistic expectations of the overall project manager. Most project managers will freely admit that they do not adequately understand automation to the level that is required to manage it.
Typically, project managers are construction based, or certainly lean towards the mechanical discipline, because of the nature of the engineering and construction firm’s core business. They are really in the business of building and arranging physical things. Their project responsibility is to deliver a facility (building), fit-out the building, and then install the necessary manufacturing equipment to fulfill the material flow and processes of production. That type of focus typically results in a “plugging in” of the automation as an afterthought and not part of that critical flow of materials and products through the facility. Many perceive automation as a utility, similar to the telephone system or the network architecture.
Looking at Figure 1, we can see the typical organization chart where the automation team is reporting directly to the General Project Manager as shown by the dark black lines. The remaining project roles are included in the Engineering Team area to make the diagram less confusing. The org chart also defines positions that may be an individual or a team. Additionally, more than one role may be held by a single person, but the responsibilities for that role are still part of the project delivery.
There is one sublime detail with the typical project organization structure that bears discussing. Communication paths increase as project size increases by the factor or (n*(n-1))/2. Figure 1 shows the communication channels for just the General Project Manager. This simplified scenario has nine organizational roles identified, which produces 36 communication paths for the General Project Manager. In a complete organization model with a full automation team and the non-simplified project staff, communication channels are numerous. The detail mentioned is the fact that of the 36 potential communications that are taking place, 21 are between an automation expert and the General Project Manager. Even in our simplified model, the number of potential miscommunications with the automation teams is significant.
Figure 2 shows the same project team with the addition of the automation project manager. It also includes additional roles in the automation delivery team. With this model, the automation project manager interfaces with the other disciplines to manage the information flow and ensure that the automation component is properly integrated. An expected result is that the number of communication paths decreases, even with a larger automation team. The number of communication paths is now totaling 15, with only one path to automation. Not only are the number of communication paths reduced to automation, they are also much more reliable because of the automation project manager’s understanding of the overall automation delivery as discussed earlier.
Project teams also tend to underestimate the complexity of automation and as a result, the master project schedules are often inadequate and inaccurate. Construction activities are generally well defined, predecessors and successors are complete, and the proper milestones are in place. However, automation typically is not as well scheduled and most predecessors and successors are incorrect or even worse, critical activities are not even shown.
On many projects, the automation team tries to develop their own project schedule. This dual scheduling can, and often does, lead to issues with due dates, resources and dual record keeping for the automation team because the team is already overworked. The Automation Project Manager serves a significant role in the scheduling process. Without an Automation Project Manager, the burden of the scheduling falls on the automation team leaders, detracting from the technical leadership they need to provide to the team. The automation project manager adds value here by working with the master scheduler and the project team to correctly integrate automation activities into the overall schedule. Most times, this exercise brings to light several misunderstandings that affect the project schedule. The APM may chose to keep a detailed schedule as a management tool and must dedicate time to the schedule and its synchronization with the Master Schedule.
It is easy to understand why project delivery teams continue to struggle with correctly integrating automation into their project plans. Ask any seasoned manufacturing director or engineering consultant and they will undoubtedly tell you that the biggest advances in manufacturing over the last twenty years have come as a result of automation and the information it provides to the business. Perhaps in the days when automation meant panels full of relays, and machines were islands of automation, and integrated architecture was a dream, then automation was probably manageable by the general project manager. The boundaries have expanded today to where automation is treading on the turf of IT and the two disciplines fight for ownership of the communication infrastructures and information boundary areas. They squabble over who owns Ethernet communication networks and how to get the information from the manufacturing process into the business process. This area of interaction and the management of the “middleware” space is another area that requires an additional coordination and usually justifies a dedicated automation project manager to manage, understand and direct these diverse teams.
Research has shown that the utilization of a dedicated automation project manager was one of the contributors to delivering successful projects. This finding is significant in that it clearly represents the need for automation project management. David Adler, retired Eli Lilly automation consultant and now with Brillig Systems, has done similar work and has made some clear discoveries as well. As a result of his internal studies, he has stated that: “One of the key factors for project success is having the right people with the right skills”.
Most project failures are not a result of implementing the wrong technology. They fail because they don’t have the right team. In projects with an automation component, the fastest way to increase your likelihood of failure is to overlook the vital role of the automation project manager. These projects need someone who can quickly grasp the entire scope of the automation component and begin applying solid processes to the project. The project needs the automation project manager to not only understand the automation scope, but perform the careful dissection of the necessary automation skill sets required to meet the assigned deliverables. As we saw in Table 1, there are many possible skill sets that fall within the automation boundary and managing this puzzle to ensure that all the pieces come together with the rest of the project is an extremely valuable role.
