Did You Hear What I Said?

[article]
Summary:

Software projects are complex endeavors that rely on clear communication for success. If communication methods are mismatched or leave too many gaps, your project could suffer, and you could be highly frustrated. In this column, Karl Wiegers details potential problems to be mindful of, and strategies to use, when communicating about a project.

I once facilitated a project retrospective for an Internet development team that included several software developers and some visual-design and human-factors experts. One of the visual designers complained that she never knew the status of the software side of the project.

"What do you mean?" asked the lead software developer.

I once facilitated a project retrospective for an Internet development team that included several software developers and some visual-design and human-factors experts. One of the visual designers complained that she never knew the status of the software side of the project.

"What do you mean?" asked the lead software developer. "I sent you emails all the time with status updates."

"Those emails didn't do much for me," replied the visual designer. "I figured you'd walk over and talk to me if anything important came up. I felt like you had excluded me from the loop."

Obviously the software lead and the visual designer had very different communication styles and expectations. Problems arose because both parties communicated in the way that was most comfortable and natural for them, without regard to whether that met the needs of their counterpart. As a result, important information was not exchanged and feelings were hurt.

Mismatched Styles
Communication gaps often arise simply because people have different preferences for how they communicate and how they interact with others. For example, a talkative extravert who cheerfully broadcasts information to an introverted counterpart might wonder why his colleague just sits quietly without responding. "Is she bored, asleep, distracted, or mocking me?" the extravert might wonder.

In fact, the introvert might simply be absorbing the information and processing it before making a response. The extravert might well charge ahead with additional input, without giving the introvert time to collect her thoughts and formulate a reply. The introvert feels trampled and ignored, while the extravert feels like he's talking to a wall.

Some people are oriented toward details, while others want only the big picture. It's easy to overwhelm a manager with the rationale for decisions you've made, when all he really wants to know is the status of the project at this moment. When the manager waves off the detail and impatiently waits for you to get to the point, your reaction could be, "He hasn't heard a word I've said" or "He must think I'm an idiot." A request for testing status could elicit a response of "Lookin' good, right on track" from someone who thinks in terms of generalities. But perhaps the inquirer really wanted to know exactly what percentage of the test case has been executed and what fraction passed.

Communication involves both sending and receiving, but too often we emphasize the transmission. Software projects create a variety of documents that bridge a communication gulf between one part of the team and others. Such documents include requirements specifications, project plans, quality assurance plans, and test procedures. Although the purpose of those documents is to convey information that lets other people do their jobs, we usually write them from the point of view of the author, not the document's receiver. Consequently, the document's receiver might say, "Once again, this thing is badly organized, lacks information I need, and includes a bunch of stuff I don't care about." Consider developing templates for such important "bridging documents" collaboratively, with both the producers and the consumers sitting down together to discuss the structure, content, depth, and style.

Close the Loop
Unless we understand our own communication style preferences and discuss communication expectations with our colleagues, we can expect many frustrating conversations. For example, when I'm having a one-on-one conversation about

About the author

Karl E. Wiegers's picture Karl E. Wiegers

Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon, and the author of Software Requirements (Microsoft Press, 1999) and Creating a Software Engineering Culture (Dorset House, 1996). You can reach him at www.processimpact.com. You can find more than 35 of Karl's articles at www.processimpact.com/pubs.shtml

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09