Overcoming Engineering Challenges in Automation

Even when working with the most off the shelf parts, robotic arms, conveyors, and components, every automated machine, embedded hardware, or engineering project requires some amount of custom engineering. 

• Your mechanical engineers need to replicate the shape, structure, and parts involved in the assembly of your products. 
• Your electrical engineer needs to maintain precision power, signaling, protocols, and uninterrupted connections. 
• Your software engineer needs to manage HMI control of a series of custom programs, IOT connectivity, sensor assisted data collection, and language programming. 

The most complex automation engineering challenges revolve around confronting the undiscovered engineering required to make something brand new. In any custom project there is always risk that the request will not be affordable, will not be done in a reasonable time, or simply cannot be done. In close collaboration with customers, your engineering partner needs the expertise, discipline, and teamwork necessary to confront challenges and realize quality cost effective engineering solutions.

Types of Preventable Engineering Challenges

Automation engineering challenges often derive themselves from preventable missteps caused by inexperience, lack of judgment, and lack of upfront planning:

Miscommunication- 

• A critical design detail gets left off the request until late in the prototyping phase and the customer lacked understanding about the costs and risks of extra engineering.
• The contractor divulged that they have an exclusive contract to use certain parts on the design after part selection. 
• A part makes sense for the engineering to fit on the right, but the customer did not mention the warehouse footprint needs it to be on the left. 
• The customer changes the material used for raw stock, the dimensions of the parts used in their products, or makes changes in the tolerances in project units after design.
• Stages continue without mutual understanding of cost, delivery time, and function. 

Lack of Schedule- 

• The project starts without demonstrating a Gantt schedule or gated stages of engineering. 
• There are no regular scheduled meetings between customer and engineering team and no framework for ad hoc communication. 
• There is no agreement for what would be considered a delay, a late change, or a missed deadline. 

Lack of Engineering Discipline- 

• The engineering team agrees to every change and add on requested by the customer, even after the prototyping stage. 
• Return on Investment (ROI) failure and exponential cost increases are ignored in favor of adding new functions. 
• The engineer makes the customer responsible for technical details or part selection. 

Rotating Staff- 

• The automation project lead leaves the team and provides no training or backup to the next project lead. 
• Every meeting wastes time on introducing new team members. 
• Every meeting wastes time catching up unfamiliar staff to the scope of the project. 
• Your project gets handed off to an inexperienced staff member without input on repeat until no one can really confirm the original goals, scope, and stopping point of the previous staff member.
• Everytime the customer replaces their project lead, the new lead wastes time making the engineering team ‘resell’ and ‘repitch’ a project that already has a contract.

Lack of Supply Ownership- 

• A critical part was chosen for the project, but the engineer overlooked a notice that the part would soon be discontinued. 
• An expensive part was chosen when a cheaper more effective alternative was available. 
• The engineering design relies on excessively expensive custom parts when the same solution could be achieved with fewer cost effective off the shelf options.
• An engineering team gets hyper invested in specific supply selections when they should be designing for families of parts with alternatives.

Lack of Leadership- 

• Leadership will not define what engineering metrics represent success and what metrics represent failure. 
• Leadership will not agree on what responsibilities the engineer has to the customer and vice versa.
• Leadership won’t agree on the definition of a Change Order or the costs involved to make that additional modification to the engineering project.
• Leadership wants to skip Factory Acceptance Testing (FAT) and other critical quality control procedures to save time.

Siloed Engineering- 

• Every stage of the project is farmed out to third party engineers, none of them ever talk to each other.
• A third party electrical engineer turned in a workable electrical design choice that made engineering impossible for the third party software engineer and circling back to your for hire engineering contractors takes time and effort.
• An early design mistake was missed because only electrical engineers were in the design meeting and a mechanical engineer would have noticed the flaw right away, and vice versa.
• Every time there is a project update, the project manager wastes time informing each engineering team member separately and only gets their individual perspective.

These challenges may seem daunting, but we want to show you how collaboration with a quality engineering partner can mitigate these preventable risks and accommodate the challenges of custom engineering design.

Communication with Customer is Number One

The most crucial step in overcoming engineering challenges in automation is nailing down consistent communication between customers and engineering team. The number one cause of scope bloat, overcomplicated, costly, or unfocused changes past prototyping, is miscommunication between the customer and the engineering team. You can apply these strategies to set down the rules, support structure, and communication policy on both sides of the engineering project partnership:

Designated Staff- 

• On the engineering side, the engineering team establishes a project lead and a team of engineers. 
• Team members remain at the same point of contact throughout the entire project (i.e., if the customer needs to talk to the mechanical engineer, they talk to the same mechanical engineer from beginning to end of project). 
• Each role filled trains an informed back up in the event of absence, injury, or replacement. 
• On the customer side, the designated project lead remains the same through the entire project. 
• The customer project lead has authority to make unilateral decisions on behalf of their business.
• The customer project lead also trains an informed back up.

Scheduling

• The customer and the engineering team agree to a mutual schedule for the project.
• A Gannt chart with stages of completion projects when the various stages of the project start and finish.
• Both the customer and engineering team establish preferred means of communication (phone, email, in person, video conferencing, etc.).
• Regularly scheduled meetings are planned with allowances for ad hoc meetings and communication. 

Defined Teamwork Between Customer and Engineering Team

• The customer keeps their engineering requests high level and goal based. They provide basic scopes (‘we want to make x units per year in y tolerances’). They only get into technical, or part based requests due to preexisting contract requirements, brand preference, or outliers specific to their business.
• The engineering team focuses on achieving the goal by taking ownership of the technical specifics of the engineering.
• The engineering team starts by asking questions about the customer business, products, and growth targets.
• The customer and every team member from the engineering company meet in the same room or call during critical stages and progress meetings.
• Mutual NDAs are signed so both sides have the freedom to share IP, build on trade secrets, and provide access to each other’s data.

Mutual Commitment to the Design

• The customer commits to the specific raw stock materials used in their end product, never changing them past the design phase.
• The customer commits to the tolerances and dimensions of the product targeted by the automation project.
• The customer mutually approves changes to their products with the engineering team under the expectation that even a minor product design changes cause engineering change orders.

Mutual Agreement on Goals

• Both agree to a Statement of Work (SOW) that defines the partnership during the engineering project.
• Both accept specific definitions of success and failure for the project (i.e., Factory Acceptance Testing standards (FAT)).
• Both agree on a budget. This can include gating payment release in mutually approved stages of completion.
• Both agree to stay in scope unless absolutely necessary for the completion of the project.
• Both agree on definitions of out of scope changes and the costs associated with making out of scope changes.

Once you have set up this strong framework of mutual communication your engineering team can authentically approach engineering challenges.

Single Source, Vertically Integrated Engineering Team

When a challenge comes up in the engineering room, every member of the team needs to be present while scoping the issues.

• Vertically Integrated Success- Even if only one engineering discipline is responsible for the specific engineering, every engineering discipline needs to be in the room. These engineers inform each other, mitigate costly issues in the later stages, and offer elegant solutions that support the overall engineering. These engineers create a cohesive product.
• Steady Timelines- Especially when dealing with months or years, a change or challenge has a domino effect on engineering delivery timelines down the road. With a single source engineering team, the team actively tracks the stages of their engineering, works alongside each other during collaborative stages, and makes seamless handoffs for project goals.
• Cross Team Mobilization- In the event of an issue, defect, or unexpected complication, a vertically integrated team mobilizes. The project manager pulls in every engineer from every stage of the project. 
• Cross Functional User Experience- Single source collaboration between software engineers, mechanical engineers, electrical engineers, industrial designers, and technical writers creates a seamless handoff between engineering stages. Concurrent engineering support translates to a uniform user experience.

Once you have the team in place, you are ready for your engineers to tackle the challenge.

The Right Way to Tackle Engineering Challenges

You have your multidiscipline team in place. The customer has related the high level engineering challenge. You have all your tools at your disposal. Your vertically integrated engineering team is in one room. How should a professional engineering team tackle that engineering challenge?

We would like to start by warning you against getting bogged down in the design stage. Sitting in a room together and trying to plot the mathematics, exact parts, and downstream engineering choices before trying to work on a prototype may feel like the correct choice, but there are costly inefficiencies in this approach.

• Time Wasted- There is a substantial difference in the quality of engineering progress between handling a prototype and getting bogged down in theory. You can lose a lot of time calculating and imagining when holding something  gives you a tangible starting point.
• First Pancake Theory- 9/10 times, the first proposed solution never makes it to the final build. 9/10 times the necessary modifications required are only discovered after reviewing practical CAD. Good engineering builds on failure. Early design flaws and refinement are an integral ingredient in revealing undiscovered engineering solutions. Just like the proverbial ‘first pancake that never turns out right,’ starting on a build unlikely to succeed will yield a swifter, better solution down the road than agonizing about the details.

Instead, dedicate a portion of the early design phase to something we call ‘The Proto CAD Process.’ When facing a challenge, this freeform engineering phase dedicates itself to finding solutions rather than finalizing the details. Proto CAD takes the perceived weakness of ambiguity and turns it into a strength. The best way to design is to start.

• Identifying Risk- The first step of Proto CAD involves looking at a flow diagram of all the proposed actions necessary to the engineering project. Mechanical, software, and electrical engineers plot the high level steps necessary to building the final engineering product and flag portions for high risk, high engineering lift, and uncertain engineering requirements. Each engineer separates these high risk portions of the engineering out for Proto CAD.
• Proto CAD- Each engineer gets free reign to start building solutions to address the high risk portions of the engineering project. Engineers create 3D Computer Assisted Designs (CAD), 3D print physical parts, and take steps in creating as many workable variations as possible before even calculating the math. The engineering team cross collaborates, shares designs with each other, and reviews them for quality. Their goal is not to design the perfect solution, but to compare which solution  comes closest to what is best.
• CAD Archival- The engineering team finishes testing their creative solutions and archives every single design made during the Proto CAD process into a storage folder. This folder remains untouched for the remainder of the design phase. The engineering team takes what they have learned and starts from a blank slate.
• Working CAD Model- The engineering team comes together. Using what they have learned in the Proto CAD phase, they start designing a realistic model of the final engineering solution. This CAD model represents realistic parts, cross team engineering, and best case solutions for the final design. They combine low risk and high risk engineering. They work out the math.

How to Handle Change Orders

Change orders represent the most extreme engineering challenges. A change order is an engineering request outside of the original Scope of Work agreement, usually past the prototyping stage. You should avoid change orders for multiple costly reasons:

• Supply Chain- During an engineering project, parts are scoped ahead of time to accommodate lead times. Some parts might be at the corner store, some might be months out from international vendors. A change order requires additional engineering, which means additional parts. There are no guarantees that those parts are available from the same vendors, at the same delivery times, or for the same price.
• Time- Adding a new function to an engineering project is like starting a new engineering project inside the project. The same process of design, approval, testing, and build must happen for this new portion of the project with the added complication of integrating the new technology with the original prototype. Engineering team members may also have been reassigned to new projects and may not be available for immediate reaction to change orders. This causes a logarithmic extension on the final engineering delivery time. 
• Cost- Costs for change orders are logarithmic instead of additive. You pay for additional engineer labor hours. You pay for additional parts. You pay in extended deadlines. You pay for additional testing. You pay for precision singulation and orientation.
• Risk- We’ve mentioned before that even the most off the shelf engineering project deals with the risk of creating something new that could potentially not work. An engineering project thrives on elegant solutions, uniformity, efficiency, and consistency. Adding a new function late in the prototyping stage logarithmically increases the risks for failure. Change orders create a domino effect of redesign to mitigate those risks all the way back to the beginning of the project.
• New Project- Oftentimes a change order request ignores the obvious solution. Instead of logarithmically increasing the cost, time, risk, and feasibility of one project, it might make more sense to spin the additional function off into a separate project. You can build on the lessons learned from the first automation project and save those changes for machine two.

There are good reasons for change orders. If the project cannot proceed without the change order, the change order must be considered for the engineering plan. Here is how you should plan for a change order:

• Refer to SOW- The Scope of Work contract needs falsifiable language on what is and is not in scope of the project. The SOW needs an outline of costs for additional labor and engineering hours to complete any change orders.
• Customer and Engineering Team Meeting- The customer is alerted immediately for a discussion on the change order. Early mobilization is key to reducing costs, delays, and complications. Every engineer involved with the project needs to be present.
• Change Order Verification- During the meeting between customer and engineering team, every opportunity to resolve the issue without employing a change order is discussed. Scope bloat and frivolous design requests are disqualified as motivation. Options for spinning off the change into an additional project are reviewed. The engineering team and the customer both must mutually agree that the project cannot proceed without the change order.
• Professional Agreement- Once everyone agrees that the change order is necessary, all energy gets directed toward the change order. Each party assumes their responsibilities in the change order portion of the SOW. Each party assumes increased costs, delays beyond the original projected delivery date, and practical changes to the design. Each party defines falsifiable definitions of success and failure for the new change in a change order contract.
• Project Development- The project team reassembles to tackle the change. Similar project development stages of scoping, designing, testing, and building are required for the change order. Scheduled and ad hoc communication remains open until the end of change order integration.

Overcoming Engineering Challenges in Automation with DEVELOP LLC

A custom automation system or robotic integration easily costs six to seven figures and takes months or years to complete. You need an engineering partner capable of overcoming costly challenges with a single source, vertically integrated engineering team. Tell us more about your project, schedule a virtual meeting, or call (262)-622-6104 to learn more about how we can help you automate your production today.