Automation Project Management - Org

Chart Omissions
Project Management Is as Much of an Art as It Is a
Science. It Is the Art and Science of Getting Things Done
Jun 29, 2009

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 Automation Activities and Project Phases

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.

Figure 1 Typical
Organization Chart
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.

Figure 2 Organization
Chart with Automation Project Manager
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.