Why team communications fail

Communications issues between team members or customers delay projects and increase frustration levels. See tips on how to address popular miscommunications and avoid them in the future.

By Bruce Brandt March 24, 2015

Unless you are a one person team, you will always have problems with team communications during projects. Even if you are a one person team, you will always have problems with customer communications during projects. Those are rather absolute statements, but after 45 years of projects, I can’t remember a project where there were absolutely no communications issues. In analyzing those issues some patterns emerge that point to underlying causes of miscommunication.

“Everybody does it that way.”

The “everybody does it that way” syndrome is one of the prime sources of miscommunication mainly because it stops communication. The person with the knowledge that other people need assumes that they don’t need to state the requirement to do it a certain way because the other people will automatically do it that way. The obvious trap here is the fact that most engineering problems don’t have a right answer—they have a spectrum of answers that solve the problem, and the person doing the answering will usually pick their version of how “everybody does it” again without stating that’s how they’re going to do it for the same reason that they weren’t told how the end user wanted it done.

If you are the one having work done always tell the people doing the work what is expected and how it should be done. Or, if you’re the person doing the work and you haven’t been told the expectations for execution, then tell customer how you plan to do the work.

“I get hundreds of e-mails a day.”

The “I get hundreds of e-mails a day,” syndrome is the modern version of the old “I didn’t get to your letter, yet,” syndrome of 30 years ago. This creates a different class of miscommunication because the necessary communication may have happened but the recipient hasn’t read it, so they don’t know that there’s an issue they might need to address until the deadline to address it has passed, or they don’t know the issue was resolved with part of the team and so offer a different solution than what’s already been chosen. More than anything this syndrome causes confusion because something the team thinks is already handled is suddenly back open for discussion. Also the late responder may feel set upon when the team pushes back on their solution.

The most obvious solution to this is to request a return receipt from the e-mail program so you’ll know that the e-mail has been at least opened. The other tactic is to set a deadline and if you haven’t gotten a response by the deadline then call the person to ask for their input. One other solution to this problem is to call the person before sending the e-mail to alert them that something requiring their immediate input is about to come their way. This last tactic is almost required for certain people who are chronically overloaded, which are becoming more and more all of us.

Unmet, unvoiced expectation

The “unmet, unvoiced expectation” syndrome is probably the most common communications failure, and not just at work. This is a superset of the “everybody does it that way” syndrome since it also encompasses all the things that people expect whether or not they are part of the typical deliverables. The biggest problem with this communications failure is it’s a land mine waiting on someone to step on it. You can always identify when you’ve stepped on one of these because you’ll hear “I expected…” or “I would have expected…” followed by an expression of an expectation you’ve never heard before. These can be best described as disappointments over something you either did or didn’t do and are often characterized by the word more as in: “I expected a more professional job out of a company like yours.”

Like the earlier syndrome, this one could be corrected by ensuring that anything anyone expects is put down in writing at the start of the project and that list is kept updated as the project progresses a monumental task at best. Clearing up this miscommunication can be very difficult since even the person with the expectation may not be completely aware of it until the mine blows up. There aren’t any obvious solutions but the one tactic that can work is asking lots of questions and particularly open ended questions so the responder has to think about what their expectations are. This is also a great place to play the little kid and keep asking “Why?” until you’ve uncovered as much as you possibly can. Like the first syndrome this is also a great place to over share what you’re expecting to do and what you’re expecting them to do in an effort to trip the mine before actually stepping on it. You may get some blowback when you do but you probably won’t lose any limbs.

This is by no means an exhaustive list of why communications breakdown but hopefully it will stir some thought on the subject. So what kinds of communications issues do you face and how have you learned to fix or avoid them? What’ve been you most and least successful ways to address the issues?

This post was written by Bruce Brandt. Bruce is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.

MAVERICK Technologies is a CSIA member as of 3/20/2015