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.