Communication is the Key to Efficient Engineering

It’s second nature for people in the machine manufacturing industry to collaborate on projects. Information is shared with other departments via meetings, emails, lists, drawings etc. Everyone has the same aim: a machine, installation or control that works. Why does working together often go wrong? And even more importantly, what can we do about this? 

For a successful collaboration, seamless data exchange is extremely important but also very difficult because every team member interprets data differently. Take a simple project plan for example. One person sees that the team is behind schedule, another person needs more information before they can continue and someone else sees the exceeding costs.

Different Interpretations

Take an example from practice. If you ask ten colleagues to draw a conveyor belt, it’s likely that all ten will draw it differently. Maybe you’re surprised or maybe you find it funny, but this is normal for most technical companies. Every engineer interprets tasks in their own way. We think that we are talking about the same thing, yet we are interpreting the same thing differently. How is that possible?

The Art of Omitting

Speech is a great way to share information, but we make so little use of it. Many engineers’ way of communicating ‘efficiently’ is leaving out as much as possible. There aren’t many engineers that wait for the full specification before starting a new project. This results in incomplete information being delivered that is based on the engineers’ previous knowledge. We assume that the person on the receiving end can fill in the gaps. But the way in which this is done and whether the interpretation is what the engineer intended is a different matter.

Technical issues lead to a complex collection of data, which results in different departments having to collaborate to find a solution. Our ‘simple’ conveyor belt has dozens of aspects that need to be changed– part numbers, ratings, motor types, speed, control types, product detection, voltage, power etc. Do you expect engineers to wait for the minor details to be agreed by all every time they start a project? The answer to this rhetorical question is obviously no. But how do you make sure that everyone is talking about the same conveyor belt?

Common Jargon

Luckily, there is a solution to this problem – create a common jargon. Gather all of the engineers involved in the project and make them agree on what is meant by common terminology when talking about a conveyor belt – standardisation! Different engineering departments need different data, but they also need the general data that has been agreed for the project. This information can be shared via meetings, emails and office documentation, but it’s obviously better if a common language and structure is agreed so that the mechanical engineer, software engineer, project leader and customer know what is happening.

To establish a common jargon, you need to divide every installation, machine or control into standard functional units. This is also known as functional breakdown. Think of it like a Lego box- standard modules and a couple of small adaptations for every product. This would mean that every conveyor belt that you can think of is included.

Central Library

It can also be advantageous to save these modules and their variants in a central library, for example a document management system, or even better, a Product Lifecycle Management (PLM) system. It’s best if you agree the structure of the library in advance. The central library then allows you to store and share the data storage between different engineering departments, giving every engineer access to a digital library. There are also advantages to having a PLM system like revision management, which prevents your version from becoming outdated. 

Start by Communicating

It’s time to really start collaborating and communicating. Agree the naming structures and standard components in advance and manage this in a central system. By doing this, a common language arises, meaning that a difference in interpretation becomes a thing of the past. You communicate outside of the project to agree the jargon and then use the jargon itself during the project. By doing this, your team doesn’t need to communicate as often during the project and the project runs much more smoothly.