It is a clichéd topic – communication. However, in spite of countless books and training sessions people often miss the mark when it comes to communication FOR a project. I have seen many projects that were derailed because of how status and risks were (or were not) communicated. Over the years I have established a set of rules for myself so that I remove a key risk out of my projects early – communication. Here are my rules to ensure success the of my projects:
Rule 1: Notify team members
Establish the team and communicate to the team members that they are part of the project. This may sound silly, but I have had instances where team members in different teams did not know that they were contributing to the same project. It is important for the entire team to understand the end goal of what they are working on. Although not the complete responsibility of the project manager, this makes a big difference.
Rule 2: Don’t communicate to everyone the same way
Not all projects call for a weekly status meeting. Often the engineers – the people actually doing the work – don’t care much for the status meetings that are meant for the executives. At the same time the executives do not have the time to get into the engineering details of the project. It is important that the project manager understand this and tailor the communication to suit the group of people who receive the communication. A big meeting with everyone involved is usually a waste of time.
Rule 3: Establish a communication routine
Once you identify what to communicate to whom, establish a routine. Conduct the meeting (or send out the status email) around the same time each interval (weekly/bi-weekly etc). The interval depends on the person(s) involved and the kind of project
Rule 4: Re-iterate the goal (s) of the project – repeatedly
Individuals encounter numerous problems in getting their tasks done during a project. For projects that span multiple months, there is a tendency to lose focus and go off on a tangent to address a different problem altogether. For example, in addressing performance issues related to a piece of software, individuals can end up evaluating new hardware to upgrade the infrastructure. These things can happen very easily if a project manager does not maintain the focus of the team on the problem at hand – the reason the current project actually exists!
Do you have any such rules that you religiously follow?
Good post! A lot of projects fail because of poor communication, be it in the frequency, urgency or type of that communication. Too many projects fall victim to this completely controllable aspect.
I think one important addition to be to vary the communication based on the state of the project. Is the project at-risk? If yes, alter the frequency and methods of communication accordingly.