Human Communication on Projects

Name something that

• We assume we all know how to do on projects
• Isn't even noticed when it's effective
• Contributes to nearly every project problem
• Is blamed when a project fails
• Is hardly ever recognized or appreciated when projects succeed

No, not testing. No, not quality assurance. No, not requirements.

It might be any of these. But for this column, the answer is communication—not the switches and router kind, but rather the human kind.

Projects start with a person having an idea that gets approved and funded. Projects are worked by people using lots of hardware, software, tools, and techniques. The results are typically used by people somehow and somewhere. And throughout projects, there's typically lots of communication. Imagine trying to get a project done without any human communication. Hopefully, this is imagination and not from experience!

Communication has a big impact on projects from start to finish. How can communication be used to set a project up for success? This might involve clear statement of the project manager's role and influence—since that varies widely. What are some other ways? What can be done during the project to ensure communication continues to be open, clear, accurate, and helpful? This might involve ground rules for what is discussed in project meetings versus what is kept offline. It also helps to be sure each team member has some awareness of each other's issues and pressures. Other helpful ideas? What happens to communication when the deadline approaches, the schedule slips, or serious problems start cropping up? Here's where discipline helps, to keep discussions objective, clearly stating business necessities, technical solutions, staff time limitations, etc. How has your team coped with this kind of pressure? How are the end and the results of a project communicated?

The way projects are setup at the beginning influences the communication patterns that will be used during the rest of the project. Here some typical setups:

• The "We are one team" setup: This may have the positive effect of bringing members together. It may have the negative effect of squelching lone voices for the sake of unanimity. What are some other issues with this setup?
• The Throw-it-over-the-wall setup: This may be fun for some developers who prefer no interference during coding, so they can just pass it over for testing when they're done. This entails numerous obvious liabilities.
• The functional specialization setup: This may maximize the right person with the right set of tasks. It may also allow members to get lost in their own world and fail to be aware of pressures and issues faced by other members.
• The "Read my mind" setup: This is a common one—various members don't think of articulating important activities, events, progress, issues, etc.
• The loosely coupled teams setup: This can be great for camaraderie and improved quality from the "two pairs of eyes are better than one" effect. It may also lead to understaffed and unfocused project teams by spreading each person's time over many projects instead of dedicated to a single project from start to finish.

Well, you get the picture. I'm sure you can imagine the pattern of communication that matches each of these setups. Although the setup may not be articulated, people recognize the setup and use the corresponding communication pattern. No setup is wrong or perfect. Rather, communication is an ongoing process that can get better or worse as the project progresses.

References

1. "Improving Projects by Communicating What's Below the Surface." Eileen Strider. StickyMinds: 4 February 2002.
2. Communication Gaps and How to Close Them. Naomi Karten. Dorset House: 2002.
3. What Did You Say?: The Art of Giving and Receiving Feedback. Charles N. Seashore, Edith Whitfield Seashore, and Gerald M. Weinberg. Bingham House Books: 1997.