Don't Always Be The Messenger

From Project Manager 97Things

Jump to: navigation, search

Don’t Always Be "The Messenger"

Matt Secoske Omaha, Nebraska, USA

One of the most important roles of the software project manager (PM) is to facilitate an open dialogue between the various members of the team. Unfortunately, I have been on many projects where the opposite has happened. The PM became the bottleneck through which all communication flowed. They were "The Messenger", passing precious bits of information from one team member to the next.

For a project to be organic as it progresses, information becomes the air and water feeding the growth of the code base toward fulfilling the ultimate mission of the project. All team members rely on a constant exchange of information. But if the stakeholders are forced to channel all knowledge through the PM, insurmountable problems are guaranteed.

The PM, after being entrusted with current updates, may not have correctly identified all of the developers who need to receive that information. The originator of the message thinks he/she has fulfilled any obligation by passing it along to the PM. Once the communication channel oversight is discovered, the first team member may not remember exactly what they passed along earlier, as they have since moved on to newer challenges. The PM, overwhelmed with technological reports he or she may not understand, quickly becomes incapable of being the single point of conductivity regarding project wisdom.

There is an even more damaging role than “The Messenger”, in which a well-meaning, but clueless, PM becomes. "The Scrambler". As a project grows, so does the amount of non-technical information needed to keep it running smoothly. Developers need to know the business rules, the business champion needs to know the status of the deliverables, and various other people need insight into where the project stands in relationship to its schedule, cost, and quality metrics.

As this amount of information grows, so does the likelihood that an non-omnipotent PM will miscommunicate. The Scrambler has struck! For example, a business rule that appears to have little impact to the project on the surface, may be a major roadblock once its true intent is discovered. Sizable changes to the code base may need to be done in order to repair the damages.

A Project Manager needs to get the right stakeholders together to talk about the right topic at the right time. Finding a time to have people from disparate departments available to meet may seem daunting. The practice? The PM, trying to solve a scheduling issue says, "Cheri, I'll take this directly to Bob, and get back to you with the answer." This can work for short, non-technical questions. But, be aware that success in small ventures can insidiously evolve you into a Messenger or a Scrambler. Invariably something is missed in the translation, leading to excessive wasted time trying to sort out the repercussions.

Providing clear, open channels for communication, along with the archival of discussions and decisions, allows all team members to interact directly with each other. This keeps The Messenger and The Scrambler project manager at bay, and keeps the software project moving forward.

Personal tools