Creating a Communication Plan

Author: Neville Turbit

Communication Planning

It is surprising how few projects actually have a communication plan which shows any thought. The attitude seems to be that we will just keep people informed as we go along. On the other hand, in staff surveys, communication is right at the top of people’s complaints. Perhaps project teams are part of the problem.

Who to talk to

This is a very simple question to answer. You need to talk with the key stakeholders. If you have identified the key stakeholders, you have identified those who need to know. Your audience. What they need to know will differ.

There are also stakeholders that don’t make the “Key” list who you need to keep in the loop. Typically these people have some peripheral involvement in the process, and you need to understand why, and if they need to be included in the plan. Often, they are happy to either ask specific questions, or access particular information themselves.

What to tell them

A simple response is to ask “What do you want to know?” Each key stakeholder is a stakeholder for one or more reasons. If you have defined the roles and responsibilities for the project, the reason should be obvious. For example, the Test Manager is responsible for preparing test plans, carrying out testing, and signing off the software as being ready to move into production. They are interested in timing because they have to schedule the testing. They are interested in scope variations that might change the scope of their testing.

They are probably not interested in financial reporting unless it will have an impact on the budget available for testing. Having identified each stakeholder, identify why they are a stakeholder, and what they need to know in that role. Too much information can be as bad as not enough. Keep the information limited to what each person or group might need to do their job. If people ask for more, by all means give it, but try to start with a clear definition of what goes to whom.

When to tell them

Ask the question “How often will the information change?” For a schedule, it might be weekly. For a financial summary it might be monthly. Look at each piece of information, and identify how often it varies significantly. This will determine your timing.

How to tell them

Each project will have a number of communication events. These may be weekly reports, project board meetings, newsletters, or a myriad of communication activities. Each of these must be designed to fulfil its purpose. There are two basic ways to tell people.

You can use a medium that relies on: “Push” where the information is pushed to them in a memo, email, or presentation

“Pull” where the information is available, but they have to go find it. A web site is a good example of “pull”

In most cases, you will use “Push”. “Pull” is more useful for minor stakeholders, or detailed information that not everyone wants to see. For example, you could send out a two page Executive Summary of a report via email, and have the other 50 pages available on an Intranet.

Another aspect is how to cut through the clutter. A presentation is likely to have more impact, but if you are not going to get a good attendance, an email may be a better option. I have seen the percentage of emails that are printed and read rather than read on screen, and it is surprisingly high. A printed memo might have more chance of being read (or at least scanned) than an email.

Who to tell

Not everything need come from the team. Involving senior management to make major announcements adds weight to the announcement. It also ensures that senior management have a higher level of commitment. Having the GM stand up in front of a group of people and announce something like a date to go live can bring a lot of support to meet that date.

Creating the plan

A communication plan should be developed prior to the project beginning. It should be created by both business and IT. At an even higher level, discussion should take place as to the necessity of developing a change management plan, of which a communication plan is part. Change Management A change management plan should be produced if the project is going to have a significant effect on how the organisation operates. You need to balance this against how agile the organisation is in handling change.

For example, if there is obviously strong resistance to the implementation of a new system which will force amalgamation of several departments, and major business process change, you should be looking at managing that change. Communication is only part of the process. Change management should also cover training, HR counseling, salary negotiations, user involvement and many other aspects. It is beyond the scope of this white paper to discuss change management.

Bringing it all together

A communication plan should cover the following headings.

Audience. Who should receive the communication?
Reason. Why you are communicating with them. Why are they a key stakeholder.
Event. The communication, be it a weekly report, or a presentation to the board.
Responsible. Who is responsible for preparing and scheduling the piece of communication.
Medium. The way in which it will be delivered.
Timing. How often it will be presented.
Content. What it will contain. This should address the reason the audience will be interested in the project.