Let’s start at the beginning of the process. Mechanical design drives everything else, so the interaction between the old school toolies and the CAD jockeys sets the tone for how the controls engineers come into the picture. The paradigm to prevent here is the tendency of the toolie to view the CAD jockey as little more than a pencil for him on the computer. While this may be ok for a fresh grad with 3 days on the job, it will quickly demoralize and dishearten the younger engineer. They strive to make a difference and actually create something. Being used as a pencil beyond when they feel they have proven themselves will create long term damage to the CAD jockeys relationship with your company and/or the toolie leading them. Instead you want to foster a mentor-ship or apprenticeship type relationship between the two. The toolie has likely tried all of the improvements the CAD jockey will try to make on the tried and true method. If by some chance he finds a new one, they can flesh it out and see if it’s worth trying. The toolie can help guide the CAD jockey where to place shim packs and how to make things adjustable. The CAD jockey can demonstrate the power of modern software by quickly validating changes with weight and stress tools. They will know how to place constraints on the model to avoid crashes that the toolie may have missed. This can be a mutually beneficial relationship that can help both grow into more than what they are now. The old school toolie learns to better utilize modern tools, and the CAD jockey gets to dip into the knowledge and experience of 40 plus years in the industry. In a perfect world, this relationship could be held one-on-one until the CAD jockey is able to work independently and only needs to come back for an occasional sounding board on tough problems. Even if you have multiple CAD jockeys to a single old school toolie, it will still build the mutual respect and understanding necessary for long term growth and advancement.
Now for the wild card: the controls engineer. At first glance, the best course of action seems to be having the CAD jockey act as a translator for the controls engineers to the toolies. The CAD jockeys will typically understand a larger portion of the technical conversation as they grew up in the technology age. The gap to bridge is much smaller here. However the danger in this lies in the handling of problem prevention. As the newer CAD jockeys tend to be more sensitive to people poking holes in their designs, and the controls engineers tend to lack tact when doing so, this can lead to a volatile interaction. The trick is to attempt to separate the two conversations. If you insist that a design review take place, have both the old school toolie and the CAD jockey present during the controls kickoff and review. This should be held as soon as the concept is fleshed out so that provisions for controls requirements can be placed. If there is a better solution utilizing controls hardware, there needs to be time left to review it. If this is pushed off until right before, or even after a review with the customer you will end up with a portion of the team feeling ignored and irrelevant. The mechanical team tends to try and run independently as far as it can. 20 years ago this was common practice, but today the average job is nearly 50% controls. The control systems are far more encompassing, and far more complex, than they used to be. Because of this, the potential negative impact of a lack of provisions for controls or by a mechanical concept that is ignoring controls, is greatly multiplied. The controls engineers want to be involved in the up-front process to prevent on-the-fly changes on the floor. After all, many times this is exactly what leads to the failures they witness down the road. The problem lies in poor leaders who don’t create opportunity for the team to come together. By ensuring that the controls concepts and provisions are laid out, all requirements documented, and the architecture defined early on, you ensure that the controls team can begin CAD and PLC development much earlier than they would be able to typically.
Then you still have to consider the other half of the puzzle with the Controls interaction. Due to the large number of field hours they typically put in, they will likely have opinions on the design where they feel they can eliminate potential problems down the road. The key to ensuring that all concerns are heard, and valid ones addressed, is to follow an FMEA process. Failure Mode Effects and Analyses will define what can possible go wrong, how and what the impact is, and how to recover. The key is to determine the likelihood of a failure, weighed against the impact to recover and the cost to prevent. From here, you prevent the high risk items and the items with a large impact. Document a recovery plan should any medium risk items occur, and retain mention of low risk items as a starting point for discussion to be revisited should they occur. This ensures that the controls team feels listened to and respected. The CAD jockeys don’t feel like they are being attacked, as the toolies defend them by balancing the risk factors, and the toolies can try to ascertain the root cause in discussion with the controls engineers to get the complete picture behind the failure.
Now how does management relate to this? Many times you see managers struggling to handle the interaction between these types of employees, you see various coping mechanisms. First the worst case people pleaser, the one who will tell each group that they are right and they can’t get the other group to listen. These managers tend to believe they can sit in the middle on everyone’s good side and by appearing to agree with them and struggle with the other two, can get the best work from each group. In reality, the secret doesn’t last long. Once each the group gets wind of what’s going on, that manager either ends up trapped in manipulation games by each group or ignored and not respected. A second common failed management style is isolation. These managers tend to minimize interaction between groups to prevent conflict. They have mechanical work on a project until the customer has signed off and he feels they are done. Then they try to hand off documentation on what’s been done to controls. The problem here is that the mechanical team is forced to make decisions on items they have little to no knowledge of. Also the controls team gets a late start on the project. The designs will lack provisions for controls requirements, ensuring on the fly changes on the floor. The level of documentation typically suffers, as the mechanical team just wants to be done with the job. They will tend to slap together a quick stab at the sequence of operations and get it off their desks.
The solution to all this is for management to foster an understanding between each group, to ensure that everyone is using their strengths, instead of just throwing an open body at a problem. Mutual respect and understanding will develop as each group observes the other solve problems outside their own realm of knowledge. This can only occur when they work together as a coherent team.