The 2000s have shown that use of automation in manufacturing environments has increased, but project execution is not always successful. In the same ways that software projects fail, there are similarities as to why operations technology (OT) projects fail.
DevOps philosophies remain the same in OT as in information technology (IT), as far as getting all the players on the team to work together and to reduce complexity of projects. C-suite management wants lean project execution. Thus, automation project teams need to have clear game plans.
In the 2020 Pulse of the Profession survey, conducted by Project Management Institute (PMI), participants identified three components of project success as:
- organizational agility
- choosing the right technologies to invest in
- securing skill sets.
Creating a simple project flow process for capital or sustainable improvements will help the factory or plant to be agile and make technology plans transparent.
Implementing a project methodology
Requirements: Business needs should be considered. For a new machine, this may be a disagreement between what operations wants and what the original equipment manufacturer (OEM) can do. It could be that the operations customer has a change of mind midstream and there was no agreed-upon engineering change process. This includes what the priorities are and what the customer ultimately wants as the outcome.
Let the plant engineer set the outcome and define what the plant of factory wants, based on the stakeholders. As an integrator, you should not be defining outcomes for your customer. The integrator will say if it can be done and show the customer how to get to the end goal.
Team charter: A team charter should be defined in pre-stages allowing the project team to make decisions internally and pivot without a lot of bureaucracy, but also set up mentoring, so that, if the specialists run into a snag, they have sounding boards to discuss their decision without having to ask senior management. This means a team with defined roles that is broad enough to cover process operations interfaces, technical interfaces and financial interfaces, as well as the point of contact to work directly with the integrator.
Baseline plan: With requirements set and a team in place to execute requirements, a baseline plan can be derived. This happens in early-stage front-end loading. This is also changed once collaboration begins with the integrator and concept is compared to reality.
Execution strategy: If requirements, team charter and baseline plan are in place, then an execution strategy can be implemented. The customer and integrator must agree on the execution strategy and fallbacks if there is failure in an execution step. This is critical with obsolescence migrations due to the long time that it takes to migrate obsolete systems. If a migration takes five years, then each integration outage must be mapped down to each input/output (I/O) point and categorized into something like green, yellow, red. Green is the I/O that will go first. Yellow is the I/O that will be done if no problems in green category, and red is the I/O that will wait until the next integration point. The schedule must be mapped out but flexible. This means having an outage date and a backup outage date at the get-go.
Engineering change process (ECP): It’s difficult to not have project creep on large manufacturing projects because as the front-end loading investigations start, there may be poor assumptions made, as opposed to validating physically. Thus, installation uncovers surprises, and decisions must be made as to what is in scope or out of scope. New products being made have material changes and that makes a pilot line requirement change affecting software or hardware. This adds cost to the manufacturer and integrator.
Without a proper ECP, there is no way for the project manager on the manufacturer side or integrator side to track costs or present needs for justifications when upper management asks the question as to why costs changed. This would be the avenue for changes needing to be evaluated at the project end, not during the front-end loading process.
Randy Ruano and Automation Group, which was recently acquired by E Tech Group, have a simple way that they look at project flow called AG 5: collaborate, design, build, test, deploy.
This is an example of taking project-management philosophy and personalizing it to your company, group, or team. This is important because formal project-management processes can be traced back from their categorization, but it’s easier to talk to a project plan and present to your customer if it’s talkable and not as formal as the front-end loading process.
Project flow should be easy to talk about from the top down, which means everyone at the system integrator, from the president to the technicians who are putting the cabinets together, understands the project flow.
It seems to reduce complexity and facilitate success. One thing Ruano and his group point out is that it’s critical to understand the plant process and what the plant goes through to get funding and to do an integration project. If plants adopt simple project flow paths, then it allows contractors to know where they fit into the process, as well, and could possibly reduce timelines because, internally, it would be clear what the project flow path is, as well.
Putting ECP in the construction section allows a decision process for change paths. If engineers at the plant and the integrators understand the C-suite requirement for justification of a project and project tracking, then it makes the business side of integration easier.
