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.