July 30, 2010

Between Chaos and Suffocation: Communication in Project Teams

Picture these situations:

Three engineers from different groups talking at lunch about a bug that one of them spent most of the night fixing. Nothing wrong with that, right? Just some colleagues talking informally about their work.

A Product Manager meets with the User Interface Design Group to decide about priorities for the next release. Once again, perfectly appropriate. Part of the job of the Product Manager is to establish release priorities. Meeting with each contributing group is one of the ways this gets done.

A Sales Account Manager asks an engineer to make a change in the next release that a customer has asked for. Oops. We just crossed a line here. We would expect the Account Manager to advocate on behalf of a customer, but going straight to the engineer is the wrong way to do it.

The Client Project Manager calls an engineer at a vendor firm to ask how a particular feature in the application works. The line just got crossed again. The Project Manager on the client side should have a primary person, probably a Program Manager, who can field these calls. It’s not that the client can’t get these questions answered, it’s about getting them answered in the most productive way possible.

These examples point clearly to the need for defining communication paths for project teams. But how can you define them in a way that encourages helpful informal communication and that also ensures necessary formal communication?

At one extreme you could view a project team as a network with potential connections from each member of the team to every other member of the team. But if everyone talked to everyone else, life would be chaotic and the team would never reach its goals.

At the other end of the spectrum you could have tightly controlled communication that defines exactly who can speak to whom. This approach allows for no flexibility in the system and is overly restrictive.

Finding the middle

The answer of course lies somewhere in the middle. What is that middle? Before we answer that question, let’s look at the difference between formal and informal communication. At Waverley we think of formal communication as any communication that causes a person to change work priorities and goals, or any communication that affects productivity. Everything else is informal.

So according to this definition, formal communication includes obvious events like team meetings, client email, design reviews. It also includes any nonessential and lengthy calls to engineers by the client. The way to find the middle is to define communication paths – not to the degree that they limit informal communication – but so that formal communication can proceed in a predictable and productive way. The communication paths in distributed teams are controllable, even across remote locations, if everyone on the team understands and plays by the rules.

Early definition of communication paths will help avoid problems. As the project evolves, communication paths can evolve with them.