The methods and frequency of communicating will vary from project to project. One of the most important considerations is the project complexity. Simple projects require a minimum of communication, since it is usually a one person team and only one stakeholder involved. Focused projects require more communication planning and execution, but they typically are still relatively straight-forward since there are only a few people on the team. The project manager can often handle the communication through informal channels such as one-on-one meetings or calls to all of the team members and stakeholders. When the complexity grows to the size of Full-scale projects, the communication focus needs to shift. Now the project manager must spend dedicated time keeping everyone on the project aware of status, issues, and changes. Also, there are usually many stakeholders and stakeholder meetings on Full-scale projects. Once the complexity grows to the size of a Complex Program, the program manager is spending virtually all of his or her time doing communication and risk management. In fact, you could argue that communication IS risk management. These programs are typically managed as a portfolio of integrated sub-projects. The program manager is continuously communicating between the sub-projects to ensure they stay integrated and to guard against a problem in one sub-project cascading into all of the others.
Tools and techniques that are used by project managers to aid in communicating start with the Communications Plan. To develop a communication plan, a project manager will often do a Communication Technology Assessment. Of course, a Team List should be developed. Naturally, I recommend that when conducting a meeting - use good presentation skills, when composing a message - use good writing skills, when having a face-to-face encounter - use good interpersonal skills. However, these are not unique to projects so I am trusting you can get help on these from your Human Resources or Training department and you don't need me for that. I will stay focused on the parts of communication that are unique to project work.
The PMBOK includes Stakeholder Management activities in its communication chapter. I have placed the stakeholder management activities in Project Initiation and Project Controlling pages. Although those activities entail communicating, they are so integral to Initiating and Controlling that I felt it was better to address them in those sections.
Before I start to discuss the communicating tools, there are two topics I would like to address. The first is the understanding of a "Sender - Receiver" model. Whenever information is being communicated, it is translated from the sender's mind into a message and then from the message back into the receiver's mind. There are opportunities for misunderstanding in both translations, and for noise and errors to be introduced during the transmission of the message. That is why I believe every project leader meeds to focus on communication. Since project work is often new or unique, the chance for misunderstanding is even greater. There is no established pattern or expectation. I strongly encourage the habit of "Repeat it back." for all project communication to minimize misunderstanding.
The second is the recognition that listening is a three step process. If a team member does not seem to be listening, it is important to understand which step of the listening process is the issue. The three steps of listening are: 1) hearing, 2 understanding, and 3) judging. The Hearing step is just that. The actual receipt of the message. Team members who "aren't on the call" will not get the message. For vitual team members you may need to create special channels of communication to ensure they actually hear the message. The Understanding portion of the listening process is the team member translating the message into desired actions or changes to the project. Team members who do not understand the acronyms or whose native language is different than the normal language of project communication may hear the message that is being sent but not understand what it means. To determine if this is the problem, the project leader will need to have a directed conversation with the team member and ask them what they think the message is telling them to do. The third listening step is Judging. In this step the team member hears and understands the message and then decides whether or not they believe it applies to them and their project work. When this is the breakdown in listening the project leader will need to spend time with the project team member to determine either why the message does not apply in this special case or to explain to the team member why the message does apply to them.
Project Communication Plan
Every project manager uses a Project Communication Plan. Many project managers do not consciously develop one, instead they embrace one that has been imposed upon them from a previous project, they follow a procedure instituted by the PMO, or they conduct their communication in an ad hoc fashion. That is an approach for developing a plan - not a very good one - but an approach. I recommend that a conscious decision is made as to what communications need to occur for a successful project. I typically consider four categories of communication. All four types are not needed on every project, but they are typically found and should be planned for.
The type of communication technology used by the project manager will vary based upon the organizational constraints of the project team and stakeholders. Factors that influence the technology include whether the team is co located, the confidentiality of any information that needs to be shared, communication facilities available to the team members, and the organization's culture for how meetings and disucssions are normally conducted. Some technologies lend themselves to large group interactions and others are more appropriate for one-on-one discussions. The table below provides an assessment of the advantages and disadvantages of different communication technologies for use in a project environment.
Project Team List
The Project Team List is a list or database with all project team members and their contact information. This includes the core project team members and extended team members. I typically will also include key stakeholders on this list. The list is provided to team members to aid communication. I want project team members to know who to call when they have a question or an issue arises. The list can be maintianed in as a spreadsheet, a word document, a file for your email server, a contact list in your project eroom, or any other mechanism that is a normal resource contact management system in your organization. One caution about the list, I provide business contact information, but not personal information. In this era of identity theft and the increase of "creepy people" I try to protect the team member's privacy as much as possible.