Great Expectations: Communication Is Key With Your Automation Business Partner

Automation projects can seem daunting at first glance, especially at industrial manufacturing scales where the stakes are high, timelines are crunched and dollar figures are large. An often under-appreciated way to ease these pressures is to strategically bolster communication between clients and automation business partners. Here’s what to consider when developing a communication program designed to closely align your automation project team.

Let’s Talk About Project Communication

As with any professional or personal relationship, the quality of the communication passing between partners directly links to the quality of one’s overall experience within that relationship. As much as we might want to, no individual can read minds, predict the future or have ubiquitous knowledge. When thinking about professional teams – especially those handling technical, complex, industrial-scale projects – the demand for high-quality communication is all that much more critical, and for two distinct reasons:

1. Relationships that come together on a project-to-project basis lack the benefit of lengthy normalizing interaction between organizations or individuals (such as you might have with internal teams working together for some time). This situation leaves tremendous gaps in familiarity that can translate into incorrect assumptions, large misunderstandings and tense corrective pivots.

2. The conditions that initiate project team engagements tend to focus on a single or few opportunistic objectives, inadvertently tilting the entire upcoming project relationship toward goals that are too strict. Without ongoing communication to expand expectations, these goals may consume the project. For example, if a project is initiated based on a low bid from a new vendor, the vendor may be compelled to make all of their design decisions around minimizing cost, at the expense of performance benefits that the customer may have otherwise desired.

Projects involving automation tend to suffer from these risks a little more than others, in that so much of the project’s deliverables are “under the hood,” so to speak. Digital assets (such as program code or data structures) are not things that can be evaluated laying out on a workbench, and so greater effort is needed to gain full understanding and buy-in across the team. Without this effort, we risk missing significant opportunities within the project, or worse, falling victim to the tragedy of assumptions.

How do we reduce all of these potential hazards, manage risks and improve our overall project experience? We communicate!

There are many formal communication programs and structures that you can choose from. We won’t name or choose a preferred system here, as they vary widely depending on industry, application and intent. Instead, we list the core topics below that we feel should be included in any communication scheme used on automation projects.

Topic 1: Constraints

Right off the bat, we suggest that project communication should immediately outline all foreseeable constraints, as these serve to bookend a project within the boundaries that both owners and vendors can reasonably serve. Constraints are any downward pressures that reign in the project, and teams should document and regularly check in on these constraints all the way through completion. Examples include:

• Budget. Automation can often solve any given challenge at many different price points, making it necessary for teams to agree on which features are “nice to have” versus “must have.” Customers should communicate their budget limits for initial purchase, allowable contingency and ongoing ownership costs, so that the automation vendor is fully informed when making procurement and design decisions. Likewise, the automation business vendor should point out needs for contingency, internal procurement nuances (such as if a requested OEM requires cash upon order, impacting customer’s cash flow) and long-term support costs (such as software subscriptions).
• Schedule. As with budget, it should be an early project requirement to communicate schedules up front, in plain and clear detail. Customers should specify not only their required delivery dates, but also startup, commissioning and clear-for-production dates. Vendors, likewise, should communicate project milestone dates, such as for initial engineering submittals, factory acceptance tests and lead times for all components (including risks of delivery issues and delays, especially given today’s market volatility). For most projects, you’ll want to isolate the most important schedule items and identify those as constraints governing the entire job.
• Technical limitations. For the most part, we see that communication around technical requirements go pretty well, as we’re all used to discussing details such as electrical power types, floor space limits, operator skill levels and the like. However, automation projects have increasingly specific requirements (again “under the hood”) presenting the need to unmask and point out technical limitations in all sorts of modern categories such as software licensing, network traffic, third- party certifications and even countries of origin (referring to global trade sanctions that may limit technical support and replacement parts).

Topic 2: Opportunities

Proper project communication with your automation business partner opens the door for opportunities of all sorts, rooted in a two-way exchange of information, experience and expertise.

• Value-engineering. You might define value as the relationship between function and cost, making value-engineering the technical evaluation of different cost approaches to reaching a desired level of functionality. Value-engineering can take place at a specific point or continuously across a project, where both customers and vendors collaborate on acceptable price points to reach their targets.
• Shared experience. In so many words, customers and vendors should both see project engagements as opportunities to learn from one another. Communication between parties expands the combined knowledge and experience within the project team, and makes for a better project overall.
• Long-term familiarity. Communication between parties strengthens long-term relationships. It also helps both vendors and customers understand the underpinnings of the other’s organization. Over time, this translates into more performative relationships, where each party is more attentive, responsive and prepared for the other’s needs.

Topic 3: Perspective

It could be said that a project that benefits one, benefits all. However, this doesn’t mean that the road towards this benefit will automatically capture all invested stakeholders and their specific interests on the project. For this reason, communication between partners should cover all involved perspectives.

• No Surprises. Admittedly, automation projects can leave much to the imagination when it comes to fine details, especially around the digital assets involved behind the scenes. This makes communication all the more important, and no topic too small or complex to discuss openly. Both parties need to identify what important factors they are tracking and measuring, so that there are no surprises upon startup.

• Project flow. In many cases, the journey is just as critical as the destination. Automation projects tend to involve choosing between multiple solutions to a single complex problem. To best navigate this design and delivery process, communication on key project workflows, decisions paths and overall project cadence should be had early on. This is especially critical in software development,  as at a certain point, what may seem like minor changes may be prohibitively difficult to implement based on how earlier structures were laid out.
• Vantage points. Sometimes, a project appears to go very well, but after what is seen as a successful completion, feedback is received that some elements of the workflow were not so great. Most often this occurs because one party did not properly account for all of the stakeholder vantage points on a project, and is the victim of poor communication that left these stakeholders out of the loop. Especially with automation, customers and vendors must together consider all possible sightlines into the job, asking questions such as, “Are we making our maintenance team’s lives harder with this project?” or “Did our fabricators building the system experience too many changes too late in the game?”

Topic 4: Expectations

You might have expected us to start this discussion with communication around project expectations, but we purposefully saved this topic for the end. Above you’ve seen key examples of communication considerations that might have brought to mind your own experiences on jobs that you’d like to actively address the next time around.

Whichever of these items speaks to you the most, it’s likely you can frame that topic into one of these three major expectation points when you kick off your next automation project.

• “What IS the project?” As a customer, you might engage an automation business vendor to deliver a plastic welding system, for example, but the “real” project tasked to you by management was to address customer quality complaints. As a vendor, you might receive an order to upgrade a filling line to a modern controls architecture, but the “real” project for your team is to gain experience with a new automation platform that you’ve been interested in trying out. All parties should communicate how they perceive all primary and underlying project goals to each other, and build their overall communication plan to serve these goals, the invested formal and unofficial vantage points, and long-term outcomes of this work.
• Define Success. Carrying on the above sentiment, the “real” project most likely has a different definition of success than the functional deliverable. Even for straight-forward, single-objective projects, communication should explicitly and formally define success criteria on a project in every possible way of importance to all parties. Customer success factors may include on-time delivery, achieving specific yield values and training that answers every question asked by operators. Automation vendor success criteria may include on-time payment, on-target profit and receiving positive customer feedback.
• Define completion. Rounding out the topic of setting project expectations, we suggest that all parties communicate openly to define what project completion means to them. Customers may have expectations of no-cost technical support for many months after a project is complete, and in the same vein, vendors may expect full handover the moment that initial training concludes. This becomes more complicated around ongoing system tuning, customer product changes, payment retention and regulatory sign-off (such as with building permits). It is critical to define what completion means to all stakeholders and from all vantage points. In a positive light, this also means that both customers and vendors will know what to expect of each other right up to and after this point of completion, giving structure to resource planning and scheduling, and clearing the way for the group to start planning their next great project together.

Choosing Your Automation Business Partner

AMS is committed to clear, honest and timely communication to ensure your project’s success. Learn more about our proven process or book a virtual application review to discuss your next automation project.