Creating a Communication Plan
|
First published May 04
|
|
Neville Turbit - Project Perfect
|
Rating |
|
|
|
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
or
- "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.
To date, 677 people have rated this article. The average rating is 3.63 - Add your rating. Just select a rating and click the button. No other information
required.
Only one rating per person is allowed.
|
Communications Plan
|
Return to the top
