Real World Project Management: The Communications Management Plan
Introduction
There are three key considerations in project communications planning:
Who needs what information?
When will they need it?
How will it be delivered?
As background to answering these questions think of all the communication events that already take place every day in a typical organization. Email going back-and-forth. Phone calls. Documents being created and read. People attending webinars. Instant messaging sessions. Plus the all-important chance meeting in the hallway or around the water cooler.
An interesting fact about all these communication events is that so many are taking place between people in so many dispersed locations, some with people halfway around the world, others with people just down the hall. It’s a rich stew, this ongoing network of conversations, some occurring by chance, others by design.
Get With The Plan!
This is the environment the Project Manager needs to consider when developing a Communications Management Plan. According to SoftPMO the purpose of the Plan is to:
Identify the information requirements of the individual project stakeholders and team members.
Define the sources of the information for collection or production of project related information.
Document the flow of the information, time frames, recipients, and frequencies.
Select the technical means and forms of effective delivery.
Forecast the resources that are necessary to execute the plan.
1. Identify the information requirements of the individual project stakeholders and team members.
Doing this well assumes you know who the team members and stakeholders are, where they are located, what their roles are/will be, whether they are permanent or temporary members of the staff, and how to communicate with them.
That’s all pretty basic information but could take some doing to gather. Doing this well also assumes you can identify “information requirements” in advance. This isn’t always easy, especially if the project you’re managing is unusual or one of a kind. As the size and complexity of the project increases and as the work justifies the creation of different project teams, you need to take into account that not only will different people be performing different roles on the project, in some cases they will be performing multiple or overlapping roles.
You don’t need to get too fancy or detailed in communication requirements at this point. Let general questions like the following be a starting point:
How do I communicate with X, where X is a client, a team member, a sponsor, or a stakeholder?
What do I need to communicate to X?
What does/will X need to communicate to me?
How does X communicate with Y (another team member or stakeholder)?
What are the differences in requirements between team members and stakeholders inside the organization and those outside the organization?
2. Define the sources of the information for collection or production of project related information.
Once you go through the requirements process and understand “who needs to know what and when,” you also need to consider where the information will come from. Answer questions like these:
Do systems or processes already exist for obtaining the needed information?
Are systems already in place for tracking cost and schedule information?
Do we have to supply such systems for the project?
How secure or private is the information associated with these different sources?
Are there already recurring events (meetings, reports, presentations, etc.) that are potential producers and consumers of project information?
At this point it makes sense to be thinking about efficiency and reusability; whenever possible, try to use or adapt existing systems or processes rather than recreate things every time a major report or meeting has to be scheduled.
3. Document the flow of the information, time frames, recipients, and frequencies.
Start by drawing a simple table having two basic dimensions where you estimate the time frames and frequencies for the different types of project information that need to be communicated among the different groups of people, e.g. :
People (e.g., PM, team members, business owner, other stakeholders, etc.)
Project Information (e.g., resources, schedule, work performed/to be performed, progress reporting, issues, etc.)
Meetings and reports emerge here as formally defined mechanisms for capturing the flow of project information. At the same time keep in mind that it should also be easy to exchange information in an ad hoc fashion without waiting on a formal report or a meeting.
4. Select the technical means and forms of effective delivery.
Piggybacking on existing communication channels should be done as much as possible. You also want to make it as easy for each participant to easily locate and organize information by project, especially when individuals are spreading their time across multiple projects.
Some project information can be communicated face to face, some by email or phone, some via documents, some via stand up meetings or conferencing systems, and some via internal or external network resources (e.g., a Facebook site dedicated to publishing project information intended for public consumption, a dedicated internal project Teamsite built using a tool like SharePoint, etc.)
Be sure to balance controlling the flow of project information with a desire to make communication processes as flexible straightforward as possible. A classic example is the use of email for distributing copies of documents to multiple people for review and comment prior to a meeting, versus posting the document once on an internal SharePoint site where comments can be easily aggregated and shared. The latter may be highly desirable from an efficiency standpoint but there may be a few key individuals who resist giving up email. As Project Manager you may need to accommodate multiple communication channels.
5. Forecast the resources that are necessary to execute the plan.
Taking into consideration all the methods you’ll be using to support project communication, you need to estimate the resources required to develop or support these methods. Your goal may be to minimize development, ramp up, and support costs in relation to other project resources.
Wherever possible you’ll want to emphasize templates and reusability for basic communication. Probably the most significant element is a central web site (we call it a “Teamsite”) that integrates communication, document management, and collaboration; you need an online place to go where all the project “basics” are available to all team members and stakeholders as well as up to date information about ongoing work. Having a central site does take resources but the benefits of minimizing duplication and making it easier to keep everyone on the same page about what’s going on will be significant.
So What?
Given the effort required to develop a project communications plan, what are the benefits?
When you understand the various channels available for project communication you can do a better job of matching the channel to the message.
When you understand the different channels available for people to receive information — including their preferences — you can do a better job of making sure they’re all updated at the same time about project events and performance.
Given the importance of good communications to project success, understanding the costs of maintaining and using different communication channels is just good management practice.
Maintaining effective communications with team members and stakeholders is one of the best ways to manage and control potential risks to the project.
Related Reading
Some Implications of the Overlap Between Project and Process Roles
Toward a Definition of Enterprise Mobility, Part 1: Key Dimensions
How Project Management Roles Impact Use of Mobile Technologies
Acknowledgement: Thanks to Michael Kaplan for commenting on an earlier version of this article!
Copyright © 2014 by Dennis D. McDonald
