This is an excerpt from the July/August 2013 issue of InTech magazine by Raymond Teaster and Dave Adler of Brillig Systems. To read the full article, please see the link at the bottom of this post.
Over the past five years, we have had the opportunity to review summary benchmarking data from more than 100 automation projects. This benchmarking effort, conducted by coauthor Dave Adler, includes everything from detailed cost analysis to the opinions of company management about their automation systems. This benchmarking research reveals that the top three measurement criteria for project success are scope, schedule, and budget – and that less than 20 percent of projects were actually able to achieve their goals in all three areas. That means that, according to the research, when a company decides to embark on an automation project, there is an 80 percent chance it will fail to do what the company intended, be delivered later than expected, or cost more than expected. A sobering thought to say the least.
Why are automation projects so challenging? The typical automation system is complex and includes a wide array of technologies, including field instrumentation, computer system hardware, software applications, and data management. It is 
difficult to master one component of automation technology in a lifetime, much less become an expert on all the diverse and rapidly evolving technologies needed to control manufacturing facilities today. The lead automation engineer is usually assigned to manage automation projects, but the skills required for project success are significantly wider than technical expertise. The skills of planning, organizing, motivating, and managing resources are needed just as much as deep technical expertise on an automation project. The proven way to improve the automation team’s odds of success is to use project management tools and processes.
The benchmarking research also reveals that successful automation projects have common characteristics: good upfront planning, strong support from operations leaders during implementation, an understanding of the work processes, the ability to define key user requirements, schedule and budget management, deliverable and key project event monitoring, and the skilled automation professionals required to start up and execute the project. Understanding and adapting traditional project management tools and approaches to automation is the only way to ensure these characteristics are all delivered. In this article, we will discuss these three measurement criteria for project success and ways to achieve the project goals.
Creating a robust scope
Scope requires understanding the manufacturing process, anticipating future operation needs, and defining good workable automation solutions. The drivers for scope include project objectives, operational needs, long-term maintenance requirements, safety, and quality. The first step in developing a scope is to understand the business drivers and justification for the investment in automation. The next step is the automation philosophy. It includes the operational intent, long-term support strategy, quality and regulatory requirements, safety approach, and information management practices. The final step in scope is developing requirements. These requirements include instrumentation, wiring, panels, computer system platform, automation software, information management, validation, and the operational user requirements. The user requirements will detail how the operation personnel will use the automation system to control the manufacturing equipment. The requirements will clearly specify what the automation team must deliver. The scope document also clearly defines those items that are out of scope. Determining the boundaries is critical for a robust scope. The scope does not include the method to deliver the automation solution, or its cost and schedule. The automation team will define these later.
The automation professional needs to obtain buy-in from stakeholders. The automation team's challenge is to explain the capability of automation and help the stakeholders visualize the automated operations. Typically, stakeholders are the overall project manager, process engineers, tech service, quality, and especially operations and their management. Stakeholders will want the maximum amount of capability for the lowest possible cost. The stakeholders' concerns should be taken seriously, as they often do not understand automation. It is important to clearly explain the features and capabilities of the automation system in language they can understand. Take the time to meet directly with each stakeholder. Then to move the process along, get all the stakeholders together in a group discussion. Ensure that all the stakeholders agree and sign the scope and requirement documents. Do not start executing the automation project until they do.
So what can possibly go wrong now that the scope is well-defined? This is where the real fun begins. As the project continues into the execution phase, the engineering process continues to evolve. The facility design changes, and the automation user requirements are affected. The closer the project gets to start-up, the more the operations folks and process engineers will worry about the overall design. These changes are calledscope creep. Each change in itself might be insignificant, but added together they become significant. To minimize potential scope creep that threatens every automation project, the automation professionals need to have an effective change control process. They need to be prepared to just say "not in scope." Or they need to make sure any change that affects automation, no matter how small, is accompanied by approval for a change in budget, schedule, achievability, and any additional risks.
If the company starts automation implementation without knowing what scope to deliver, there is little chance for success. An experience on a fast-track project in the early 1990s shows what will happen. The site management and overall project manager wanted the automation team to get started. Unfortunately, they listened to these stakeholders and ordered instruments without finished piping and instrument drawings and wrote process control application code without approved requirements. This project was late and had significant cost overruns. In contrast, on another fast-track project of similar size and scope in the mid-2000s, the automation team took a different approach. Again all the stakeholders wanted the team to get started. They said no to starting without a scope and took a lot of heat. It took two months to define scope and develop the piping and instrument drawings. This "front end" investment paid off, since the automation team was able to make progress in record time when the team actually started writing code and ordering instruments. At the end of the project, they were on schedule and on budget, and the implementation worked well.
Effective schedule development
While the project scope describes what is to be accomplished, the schedule answers the question, "How and when are we going to do it?" The project schedule communicates the intended plan for the project and where the project is in that plan. A well-developed schedule is a logical representation of the project plan and proof that the objective is possible. The schedule is also the project manager's best tool in evaluating the impact of changes to the project. Too many project teams skip creating a schedule so they can get started making progress. The usual excuse is "We know what we're doing, so we don't need a schedule that management will just beat us up with later." The single best way to assuage management fears is to illustrate to them that there is a logical plan, and it is being followed.
The act of developing the schedule helps to reveal dependencies from inside and outside the project and identifies potential risks to the project. A feature of automation projects that makes them difficult is that the work processes can vary depending on the facility's operational strategy (continuous vs. batch), level of automation, and control system (programmable logic controller vs. distributed control system). Creating a schedule defines those work processes and allows the automation professional to get stakeholders to agree to the plan.
It is important to get organized when creating the schedule. The organization of the work components is called the work breakdown structure (WBS). Consider how the automation team will accomplish the work, as well as how the project's product will be delivered when developing the WBS. For automation projects, this can relate to the construction sequence or the shutdown plan. Effective schedule development involves visualizing the installation of the hardware and software and organizing the project schedule to support that strategy.
Determining the appropriate level of detail for a schedule can be difficult. If tasks' durations are too large then the schedule will not be very useful, but if durations are too short then the automation team will spend its time updating minutia for no benefit. Project Management Institute's PMBOK Guide and Standards says that the schedule activities should be "to the point at which cost and activity durations for the work can be reliably estimated and managed." Using identifiable events in the work process can help define activity detail. Consider the completion of a document's first draft, for instance, or the review of a software module. Consider as well how others might use the schedule. For example, stakeholders will use the schedule to know when they will be expected to attend reviews. It is also important to identify milestones that management will consider important for tracking the automation team's progress and that downstream groups will use to kick off their activities.
Keeping the project schedule current is essential to successfully managing a project. We have seen project teams avoid updating schedules, because they were not prepared to admit that the due dates were no longer realistic. It is far better to face reality, so that recovery plans can be formulated and integrated into the schedule.
Regular project schedule reviews help team members understand how their work fits together and why it is important to complete tasks on time. Plan schedule review agendas to highlight important aspects of the schedule and avoid reviewing the entire schedule repeatedly. Graphic images generated from schedule information can be used to emphasize important schedule data rather than expecting everyone to understand a 1000 line Gantt chart. These graphics can be posted in the project area and used in project status updates.
So, if an automation professional is working on a project alone and it does not matter how long it takes or how much it costs, then do not worry about creating a schedule. Otherwise the schedule is an essential tool to communicate the project plan and to build the confidence of the project team and management that the project is under control and headed for success.
Project cost prediction
The budget answers the question, "How much will the project cost and is it tracking to plan?" To be clear, the project budget is not the same thing as the estimate. The budget is the prediction of how much it will cost to complete the project. Although the budget includes the estimate, it also includes allowances for reacting to risks that the project may encounter and amounts added to or removed from the project through change control. Having a clearly defined and understood budget is a foundational element of a well-run project.
Even though budget and estimate are not equivalent, the estimate does form the core of the budget. It is critical that the estimate basis be understood and that it contains sufficient detail to support project management activities throughout the project's life cycle. The components of the estimate should be quantified with an eye toward future change control. For software, identify and quantify software modules so that future changes can be understood. The ISA-88 software modules are ideal for relating the scope of a change to the effort required when developing batch control software. Even if the actual quantities are not known when the estimate is developed, the assumptions should be documented so that the estimate basis is clear.
Key to developing the budget from the estimate is performing risk analysis and quantifying mitigation plans to determine budget allowances and reserves. Resist the tendency to add "fat" into the estimate portion of the budget to cover risks. Reserves integrated into the estimate quantities cannot easily be managed, and the funds might not end up where they are eventually needed.
Managing the budget is a process of constantly testing your original assumptions regarding risks and the estimate. As the project progresses, use current data points to test the estimate assumptions. Early identification of trends and risks is essential to being able to create recovery plans and to demonstrate that the project is under control. Also, maintaining a running estimate at completion (EAC) is useful in identifying trends early. Significant deviation of the EAC from the budget indicates that something is going astray.
As with scope and schedule, the impact of project changes must be monitored and incorporated into the budget via change control. This is where an estimate developed based on documented quantities of deliverables will be invaluable. Those documented quantities will reduce conflicts when identifying and incorporating changes to the budget. On a recent project we made the software development estimate by assigning an assumed number of ISA-88 modules for each unit class based on our guess of each unit's complexity. Once the actual unit class requirements were developed, it was a simple exercise to identify how much the current scope was beginning to deviate from the original estimate assumptions and to quantify the potential impact to the budget.
An often neglected budget activity is the management of the budget reserves. Use change control to identify the use of budget reserves so they are documented. Review the risks regularly to make sure amounts are still sufficient given the current state of the project scope and requirements. Reserves should be revised as the project progresses, either drawn down when potential risks are no longer a threat or increased if new risks are identified. Holding budget money in reserve can be as harmful to the stakeholders as overrunning a budget, since the money could be allocated elsewhere if not needed on the automation portion of the project.
Managing automation projects
It continues to be a big challenge to manage the automation portion of capital projects. Automation projects can be managed as a unique and complex activity by adapting traditional project management concepts of scope, budget, and schedule.
If an automation professional has a passion for automation, interest in management, and empathy for others, then managing automation projects can be a very rewarding career. Everyone understands it takes at least three to five years for most automation professionals to understand the complex software, hardware, and process control technology in automation at enough detail to be a great technologist. Similarly it will take even longer for the automation professional to master leading an automation team. The needed interpersonal, leadership, and political skills are not acquired easily.
Many good automation professionals get their start in automation project management in a similar way. The reward for being a good instrument engineer, process control engineer, or application developer is to be assigned to run the next large automation project. Suddenly the engineer or developer has to coordinate the activities of other folks and is responsible for scope, schedule, and budget. As an automation technologist, the focus was on getting the technology and applications right. However if the automation professional does not take the time to learn about automation project management, the automation team will deliver a perfect automation system that was late and over budget, and they will not be appreciated by the stakeholders. Spending time in the proverbial woodshed with management is a familiar learning experience that is not easily forgotten. So learn from the mistakes of others. Use good project management practices and keep leveraging automation technical skills. Before jumping into a leadership role, read everything on the subject, attend training, get a good mentor, and never lose the passion for automation technical excellence.
About the Authors
Raymond Teaster is co-owner of Brillig Systems, an automation project management consulting company. He currently directs Brillig Systems’ Greenville, S.C., operations as well as assisting clients with automation project management. He has more than 25 years of experience successfully delivering automation projects for some of the industry’s leaders in life sciences, chemicals, semiconductors, foods, and plastics. Raymond is a professional engineer and project management professional and has a B.S. in chemical engineering from Clemson University. Contact Raymond at: raymond.teaster@brilligsys.com.
Dave Adler is a senior consultant with Brillig Systems. He has more than 35 years of experience improving pharmaceutical manufacturing using automation technologies. He has managed complex automation projects, led technical teams, and developed automation strategies. Dave has collected a benchmarking data set of more than 200 automated facilities across 25 companies in the biotech and pharmaceutical industries over the past five years. He consults on automation best practices, project management, and workforce development. He is a professional engineer, a certified automation professional, a published author, and a volunteer leader of ISA and the Pharmaceutical Automation Roundtable. Contact Dave at: dave.adler@brilligsys.com.
