Your project's Communications Management Plan contains these key elements:
Who you will communicate with. This may be on an individual basis, such as your executive sponsor, or on a group basis.
What is to be communicated. This will be determined by your stakeholders information requirements.
When the communication will happen.
How the information is to be distributed.
Capture this information from your project's Scope Statement. The Scope Statement appears in a number of the project plans such as the Change Management Plan and the Risk Management Plan. You can simply cut and paste this section from any of those documents if you have prepared them first.
The assumptions referred to here should be assumptions that could affect the execution of your communications management plan. For example, if your plan relies on the implementation of a web site and the implementation is not part of your project, you should identify the assumption that the web site will be ready for your project.
Identify individual stakeholders and stakeholder groups here. If your project has a Business Sponsor and an Executive Sponsor, identify them here individually by name. Identify the various groups by group name. For example if your software project includes a team of Java developers and a team of C++ Developers identify them by those team names. The purpose of identifying the stakeholders is to identify their needs and satisfy them so project teams, sub-teams, vendors, sub-contractors, and any external stakeholders don't have to be identified individually. The term "external stakeholder" refers to any group external to your organization who has a stake in the project. An example of such a group would be any community group (e.g. Friends of the Buffle-Headed Duck) who have a stake in the environment altering project you are performing. The term may also refer to groups within your company but external to your organization.
This section may be filled out in steps. If your organization doesn't have historical information obtained from other similar projects, you might want to use this section to describe the methods you will use to gather the requirements when you first complete the plan. Eventually, the individual requirements will need to be specified here and that should occur before you begin communicating.
Completing this part of your plan will require you to do some "trade offs". You may not be able to satisfy all the information requirements of your stakeholders because of a lack of resources. For example, if you are not tasked with managing the budget for your project, or your organization doesn't have the means to oversee a budget, requests for cost performance data can't be satisfied. Other requirements may be worth satisfying even if your project doesn't have the means to satisfy them already in place. For example, you might receive a requirement to see up to date schedule performance information on a project web site, but your project doesn't have a web site. You should determine how valuable that tool may be to the rest of the stakeholders. If the demand is sufficient you may be able to build a business case to add the expense of the web site to the project. You'll do an even better job of building your business case if you can demonstrate a benefit to subsequent projects, or operations. Of course, if the web site provides those benefits you may want to investigate having operations or your organization cover the cost of the web site!
This section simply interprets the requirements captured in the previous section into reports, meetings, bulletins, town halls, video conferences etc. For example, if your Executive Steering Committee needs to receive an update on project progress to schedule, you might describe a report employing a graphical representation of the SPI (Schedule Performance Index) here. Include sufficient detail to tell a reader what they can expect to see. For example, most stakeholders will also want to be able to spot trends in the SPI so include details around the window of indices each report will contain. Where projects will extend over many reporting periods, you might want to specify a rolling window of indices so that each period sees the addition of the latest index and the deletion of the oldest index.
Be sure to include the communication vehicles that serve to provide you with information, such as your team Status Review Meetings. Describe the meetings in terms of the information that you will receive or communicate at the meeting. Include other special meetings in this section such as Gate Meetings, Phase Exit Review Meetings (the term used in your PMP Exam Preparation training), Kill Point Meetings, Business Decision Point Meetings, brain storming sessions for risk identification and etc.
Don’t forget to include your Lessons Learned sessions in this area. Lessons Learned are an integral part of your preventive and corrective action identification and should be a part of any project. In fact, your PMP Exam Preparation training insists on it! You can describe how you’ll solicit, compile, and use the information gathered from your Lessons Learned sessions in the Tools & Techniques section.
This section describes the source of the information. By source, we mean where the information originates from, not the repository used to store it, or the means of extracting it, which will be described in the Tools & Techniques section. For example, you need status updates on the progress made on project tasks to report on project progress to schedule. You’ll likely retrieve this information from your MS Project file, and may reconcile it against Time Tracking system information from your project but the information has to originate from somewhere before it can be captured in MS Project or your Time Tracking system. The information will come from updates from the project team members responsible for the tasks. Don’t confuse status review meetings with an information source. The status review meeting is the means you’ll use to extract the information, but is not the information source.
Other sources of information might be the Time Tracking system for your project, vendor status reports, and etc.
Tools & Techniques
This is the section where you'll describe the various tools you'll use to distribute the information. The tools referred to here are both technical such as e-mail, audio conference bridges, audio/video conference bridges, web sites, and etc. You may also want to include such tools as MS Project, MS Excel, MS PowerPoint and other office productivity tools, although these are often taken for granted. You may want to include the availability of these tools to the project in the Assumptions section to ensure their availability.
Techniques refers to any special means you will use in the gathering, preparation, and distribution of the information such as a reconciliation between your MS Project information and the Time Tracking system information about time worked on your project. Other examples of techniques might be the compilation of a "dashboard” report, if you have defined one in your communications section. The technique referred to here is how you distill information from other reports into the dashboard report.
Every project manager eventually experiences the "percentage complete” dilemma. This refers to the decision on how to report the completion of the individual tasks in your Work Breakdown Structure (WBS). You should describe the method you intend to use in this section. You may choose to use the boolean method (either 0% complete or 100% complete) if the tasks are granular enough, say 1 days worth of work. You may use 0% to indicate not started, 50% to indicate started not finished, and 100% to indicate finished work. You may use the calendar method: the task is of 2 weeks duration, you’re at the end of the 1st week so the task is 50% complete (1 week/2 weeks). You may use the assessment of the team member responsible for the task, or you may use a mix of these methods. Describe the approach you intend to use in this section. Be warned: where tasks are large, that is they reflect a large amount of effort or duration, using the boolean or 0, 50, 100 methods can sqew your SPI significantly!
You described how you’ll organize Lessons Learned sessions in the Communications section. Describe how you’ll solicit, compile, and use the information from those sessions to define corrective and preventive actions that will improve project performance in this section.
This section will overlap with your Information Sources section. The purpose for including this section in your plan is to describe any special methods you’ll use to extract information from the project. For example, you would include a description of the agenda item in your status review meetings which provides the information on progress on project tasks.
Roles & Responsibilities
The template accompanying this page is reasonably informative about the information that populates this matrix. The information you include here under roles other than your own (project manager) needs to be communicated and understood by each person in the name column. You rely on the project team to provide you with information on their progress on project tasks; they need to understand that responsibility and what you expect of them. This matrix will communicate your responsibilities for project communications to the stakeholders (or at least those interested enough to read your plan), but you’ll need to educate the team on their responsibilities as described in this matrix.
This is the section that will probably be the most informative to your reading audience. If I’m a stakeholder and would like to know what information I can expect about the project, and when I can expect to hear, or see it, I’ll look in this section first. If you receive a promotion in the midst of a project and have to hand off to another project manager, this matrix is what you would use to give the new project manager a high level view of project communications. You don’t need to include specifics about the reports, meetings, bulletins, broadcasts, etc. that appear here. Readers looking for details will find them in one of the other areas of this plan.
You also don’t need to include calendar dates for recurring meetings. For example, if you intend to hold weekly status review meetings with the project team simply note the meetings occur weekly. Other meetings such as Gate Meetings may occur once only, if you’ve included a separate meeting description for each gate, or occur once at the end of each project phase.
You should include communications which mark major project milestones in your WBS/MS Project file. For example, Gate Meetings which occur at the end of each project phase should be included in your MS Project file as a major milestone. Other meetings which occur more frequently (weekly status review meetings, ad hoc job huddles, etc.) may or may not be included in the MS Project file – your call.
You put your reputation on the line with your project communications. Your efforts to verify the accuracy of the information you’re communicating are a key part of project communications. You should also be careful to inform your audience of how the information is gathered, and any risks to the accuracy of that information.
You should also ensure that any reports which reflect poor project performance are accompanied with a corrective action. Even better, when your reports show the project is trending towards poor performance describe the preventive action which will safe guard against slipping below the line. For example, if you report and SPI of 1.06 one week, 1.04 the next, and 1.02 the third week, include a section describing the preventive action defined to prevent the project slipping below 1.0. You may also want to agree with your stakeholders on the criteria which will be used to determine when preventive actions will be taken. When these criteria have been agreed upon, advertise them in your reports.
You’ll find an article on project communications elsewhere on this web site. To go to the article, Project Communications: How to Keep Your Team Engaged and Informed, simply click on this link.