Effective Communications

Project Communications:
You may not have thought of communications as an actual project deliverable, but it is.
It may not be a deliverable that your client or customer places the most emphasis on, but that's because every client and customer will take good communications for granted.

Project communications is one deliverable that you are personally responsible for and it's one that has a large influence over a project's success or failure.
Personal experience has taught me that the best managed projects that deliver on all their promises, are on time and budget can still get a bad reputation and be perceived as failures.

The reason for this failure is often because the project manager did not do an adequate job of communicating project success to stakeholders.
You need to remember that each individual stakeholder has a different set of requirements and prefers different ways of receiving their communications.

It is not be possible to define a unique set of communications and communication vehicles for each stakeholder, so the best you can do is identify the different category of stakeholder and define the required information and communication methods that best suits the group.
Generally speaking sponsors and clients are busy people who don't have a lot of time to read a lot of detail. Charts and graphs that tell them a lot about the project at a glance will probably work best for them.

Take the time to talk to them about their preferences: find out what they need to know, how they want to be communicated with, and how often.
Keeping them informed about the project performance is critical because they sign the cheque for the project - which includes your salary.

They also need information so they can keep their peers appraised about the project's performance.
Remember, they are your project champions so the better information they have, the better job they can do promoting your project.

Don't report a problem to them without suggesting a solution. For example, if you're reporting an issue or problem for the 2nd week in a row, you need to include a corrective action with the report.
Customers or Clients can be internal or external to your organisation. These people may profess no particular interest in project communications until the final product or service is delivered.

You need to overcome this disinterest and gain their interest in the projects progress. The more informed they are on the project as it progresses the more likely they are to accept the final product or service.

Community Stakeholders are an increasingly important category of stakeholder as more emphasis is being placed on organisations ethical behaviour and social responsibility, there is an increasing demand for projects to be performed ethically.

Don't forget to include yourself as a stakeholder. Your need for project information is perhaps the most important for the project. If you aren't receiving the information you need to run the project, you won't be able to share it with other stakeholders. Your needs will stem from the need to be updated on the progress of the individual tasks of the project so that you can keep the project plans up to date and identify preventive or corrective actions.

What to Communicate
What project information to communicate to a stakeholder group is tied to the information that is available for communication?  After all, you can't communicate what you don't know.

On the other hand, if the need for the information is real and gathering the information is feasible, you should make every effort to make it available.
The choice of the information to be communicated cannot be made without considering the project's tools and techniques for gathering the information and vice versa.

Project communications is not a key deliverable of the project, but it should be treated as a project deliverable.
Start with your Project Charter: does the charter contain any requirements for information? If it does, the information and its target audience ought to be included in your Communications Plan.

After identifying all the needs expressed in the project documentation, you need to seek requirements from the various groups of stakeholders. This should be done in the context of what is feasible for the project to deliver.

A project dashboard is a popular instrument for communicating project progress to sponsors and other senior executives.
The dashboard is meant to show the status of your project at a glance and may consist of the projects:
CPI (Cost Performance Index),
SV (Schedule Variance),
CV (Cost Variance),
PV (Planned Value),
AC (Actual Cost), and
EV (Earned Value).

You may also want to include such things as the top 5 risks, top 5 outstanding issues, information on change (such as number of change requests, number accepted, number of rejected, total costs, etc.).

Remember to share as much of the information reported to the other groups with the project team as these are the people actually doing the work of the project.
Your organisation may have policies or guidelines around what can and cannot be shared outside executive offices; share as much information with the team as possible without violating these policies.
You'll find sharing positive reports will boost morale, while sharing negative reports will stop the rumours that will further erode morale.

Make sure that you break the work down so that tasks performed by individual groups or departments are identifiable. This will enable you to report performance group by group or department by department and still roll totals up to report on the entire project.

The information you plan to communicate will drive your activities throughout the project. Your plans should include the information that must be gathered in order to support the information you plan to communicate.

You will need to identify who is responsible for providing the information and where the information is to be stored and reported from.
There are two questions you need to ask yourself before you commit to providing a report:
·       How do I get this information?
·       Where will I store it?
Don't forget individual accomplishments and rewards when reporting project progress. There's nothing like a good news story to keep team morale high and the celebration of a team member's accomplishment is something most sponsors enjoy hearing about.

How to Communicate
There are many different means of communication available to you - face to face, e-mail, Intranet, Internet, mail, phone, video conferences, etc., etc. These can be grouped into 2 groups: "push" communications and "pull" communications.
Push communications requires you to push the information onto the recipient as the name would suggest, while pull communications requires the recipient to actively retrieve the information from a central source.

Websites and centralised repositories are examples of pull communications, while e-mail and meetings are examples of push communications.
Preference for either push or pull communications is typically a personal preference. Some people deal with information best when it's presented to them and some prefer to retrieve it at their own convenience.

If you determine that the project must have a new tool, such as a website to satisfy a stakeholder requirement, you'll need to justify the cost with a business case. State the benefits to the project in business terms that justify the costs. You can also include benefits that supersede your project.
When to Communicate
Your communication plan will be driven by the needs of your audience and the availability of the information to be communicated.
There’s no reason why a report communicated to one stakeholder group bi-weekly, can't be communicated to another group every week.
You need to use common sense in addition to capturing your stakeholders' requirements. If for example you choose to use a "town hall" to communicate to stakeholders, don't schedule the meeting to occur weekly.

Other meetings, such as status review meetings with project teams must be done more often to avoid the project going off the rails.
I find that when the project is on track, weekly status review meetings are sufficient. When your project encounters problems, you might want to increase the frequency to better control the work. In extreme cases such as a project rescue, you may need to hold them daily.

When the project is running smoothly and you have an alternate means of identifying completed tasks, don't be afraid to cancel a status review meeting and give the team an hour off!

Remember that communications is part of the project work. You should manage that work in your MS Project file like other project tasks, but be sensible - don't overload yourself by tracking every meeting.
Finally, remember that the accuracy of the information you communicate about the project will have a profound effect, either good or bad, on your reputation. You need to do your utmost to ensure the information you communicate is accurate.
Be open and honest with your communications: tell your audience where the information comes from, how it was compiled, and how old it is.

Last of all – beware email and remember it’s good to talk.