Which of these is not a reason why effective communications to stakeholders are necessary?

Communications Management | By Dave Nielsen | Read time minutes

Communications are a critical deliverable of every successful project and a key project management soft-skill. You may not have thought of communications as an actual project deliverable, but it is. It may not be the one 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 your project's success or failure. I say this because personal experience has taught me that the best managed projects, delivering on all their promises, on time, and on budget can still get a bad reputation and be perceived as failures. The reason: the project manager did not do an adequate job of communicating project success to their stakeholders.

We hope that the information and template in this section will help guide you to choose the right information, schedule, and communication vehicles for your project.

The Major Elements of Project Communications

Who to communicate to…

You could just say that it's important to communicate with all the project's stakeholders and leave it at that, but this approach would guarantee failure. Each individual stakeholder has a different set of requirements for project information, and prefers different ways of receiving their communications. It will not be possible to define a unique set of communications and communication vehicles for each stakeholder in most projects, 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.

Executive Sponsor/Business Sponsor

Probably the most important customer(s) of your project communications. It's going to be worth your while to define a custom set of communications for each person in this category. Generally speaking, these are busy people who don't have a lot of time to read a lot of detail. Charts and graphs that tell the viewer a lot about the project at a glance will probably work best for them.

Take the time to interview them about their preferences: what they need to know, how they want to be communicated with, and how often. Keeping them informed about project performance is critical because they sign the cheque for the project (including your salary). They also need information so they can keep their peers appraised of the project's performance. Remember, they are your project champions so the better armed with information they are, the better job they can do promoting your project.

Tip: don't report a problem to them without suggesting a solution. For example, if you're reporting an SPI of less than 1.0 for the 2nd week in a row, you need to include a corrective action with the report.

Project Team Members

This is the single most populous group in your list of stakeholders. You may want to subdivide the group into sub-groups based on their roles. For example you may want to have a different set of communications for the Business Analysts and Software Developers, or for the Electricians and Plumbers on your project. This group has a different perspective on project performance than sponsors: the sponsor views the project as work being done for them. The team member views the project as work being done by them and therefore reports on project performance are a reflection on them. A good report pleases everyone - project sponsors and team members. A bad report will cause the sponsor to worry, but may negatively impact team morale.

Customers/Clients

These can be internal to your organisation, or external to it. 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 pique their interest in project progress. The more informed they are on the project as it progresses through its lifecycle, the more likely they are to accept the resulting products or services.

Partners

These are people who are doing work that is in some way affected by the work of your project. You may both be working on projects that are part of a programme, or your projects may simply affect one another without further integration. For example, you may be managing a software project that requires a corresponding database project - the database project team is your partner. Or, you may be working on a new software system that will utilise an existing web portal for customer access - the portal team is your partner despite the fact they aren't performing a project.

Community Stakeholders

These 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. One of the ways this is done is by treating those who don't belong to the performing organisation, or to the customer/client organisation, as project stakeholders. Consideration of these stakeholders must go beyond communications, but project communications constitute an important part of your ethical dealings with them.

Project Manager

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.

Project Management Office (PMO)

Your PMO may have requirements for project information that will enable it to identify opportunities for process improvement. While these needs are very much like the needs of sponsors, customers, and clients to know how the project is progressing, its focus is on the project processes, tools, techniques, and best practices it supports. Your PMO may also be tasked with reporting on project progress to the organisation. Reports which the PMO is responsible for should provide very specific requirements for information.

What to Communicate

What project information to communicate to a stakeholder group is inextricably 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 Management Plan. Your Scope Statement may also include requirements for project communications. The Statement of Work (SOW) may also have captured requirements for project communications. When you are performing a project for an external customer or client the SOW is your bible and any project communications that are part of the legal contract should be specified there.

After identifying all the needs already expressed in the project documentation to date, you need to solicit requirements from the various groups of stakeholders. This solicitation should be done in the context of what is feasible for the project to deliver. Be prepared to meet with your sponsor to identify their requirements. Be specific as to presentation: should the SPI (Schedule Performance Index) be shown as a bar graph with a rolling 6 week tally? Should it be shown as a line graph with the benchmark line of 1.0 and a rolling 6 month tally? You may even want to mock up some sample reports to let them choose the format.

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 project's SPI, CPI (Cost Performance Index), SV (Schedule Variance), CV (Cost Variance), PV (Planned Value), AC (Actual Cost), and EV (Earned Value). As a rule, you shouldn't mix schedule indicators with cost indicators, but you can show schedule and cost indicators in any combination your sponsor would like. You may also want to include such things as the top 5 risks, top 5 outstanding issues, metrics on change (number of change requests, number accepted, number of rejected, total costs, etc.), and quality (number of tests, number passed, number failed, outstanding bug reports, etc.). You should try to keep your dashboard to a handful of slides and provide supporting detail in text, or Excel format as backup.

You should repeat the requirements gathering exercise with each group of stakeholders, weighing their need for information with the project's ability to gather and communicate it. Tip: share as much of the information reported to the other groups with the project team (the people actually doing the work of the project) as is possible. 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.

Be prepared to capture and report information by stakeholder group, department, or sub-project. The individual groups on your team will want the ability to view their progress in isolation from the rest of the team. Tip: 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 for the entire project.

The information you plan to communicate will drive your activities throughout the project. Your plans should include the metrics 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:

1. How do I get this information? (i.e. what metrics do I need to capture and where will they come from)
2. Where will I store the metrics?

A failure to answer both questions will mean that either you have to alter your plan to task someone to gather the metrics, identify a tool to capture and retrieve the metrics, or drop the requirement.

Finally, 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, email, Intranet, Internet, regular 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 email 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. Be prepared for conflicting requirements from individuals in your stakeholder groups. You may have to make the final decision on which method to use if there are conflicting requests. Alternatively, you may be able to identify a spokesperson for the group who will be empowered to identify the group's requirements. The exception to this rule is your project's sponsor. Because there is only one or two of these people, you need to ensure that your communication methods suit their requirements.

Tip: 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. For example a website or tool such as Lotus Notes could benefit all projects your organisation performs, and may even provide a benefit to operations. You may also want to explore having the PMO, or Operations bear the cost of the new tool.

When to Communicate

Your communication schedule will be driven by the needs of your audience and the availability of the information to be communicated. For example, if you had the bandwidth, you could report on any metrics managed by your MS Project file daily. On the other hand, you can't report on the results of your Gate Meeting until the Gate Meeting has actually been held. There is also no reason that 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 you choose to use a ";town hall"; to communicate to all stakeholders, don't schedule the meeting to occur weekly. Tip: when planning a meeting that involves you (or another team member) communicating information to an audience, count the audience, multiply that number by the number of hours the meeting lasts and multiply that number by the loaded labour rate for that group. Avoid spending large amounts on frequent communications.

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. Tip: 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 in MS Project. You should be using the ";walk around"; style of management if your team is collocated, you needn't track each informal meeting you have with individual team members. Use MS Project to help you control the project, not overload yourself with work.

Tools and Techniques

Tools and techniques include tools you'll use to convey the information, tools you'll use to gather the information, and tools you'll use to store and retrieve the information. Conveyance tools will include email, websites, webcasts, conference calls, video conferencing, public directories, town hall meetings, and graphical tools such as Excel. What you're communicating, how you need to communicate it, and your communication budget will determine which of these tools you'll use.

There is one tool that you'll rely on more than any other to manage information about your project: MS Project (or Primavera, if that's the tool your company has selected for use). These tools are referred to as Project Management Information Systems (PMIS) by most PMP Exam preparation courses and in the PMBOK. These tools are capable of capturing, manipulating, and reporting most of your project's relevant information so you need to be very familiar with their use. There are many excellent courses available that will ground you in the fundamentals of their use.

Your organisation may employ a time tracking system in which case you have an additional source of information. Your time tracking tool should allow you to report on labour costs for your project (i.e. support the charging of time to your project code). It should also support the reporting of these costs by group and by type of work. For example it should tell you how much time was spent last week on analysis of your software project. You should reconcile the metrics from the time tracking system with your MS Project file to ensure they tally. Tip: if your time tracking system is used to generate the pay cheque for your team, make it your bible. A discrepancy means your MS Project file may be inaccurate.

MS Project comes complete with a selection of ";canned"; reports ready for your use. I have found that it's most useful feature for reporting project progress is its ability to export data to an Excel spreadsheet. Because Excel has been around so long it's feature rich and supports just about any type of graph or chart you can imagine. The trick here is to export the information you need to base your report on, then edit it in Excel. MS Project contains ample help facilities on how to export data.

I mentioned the 2 different categories for distributing information: push and pull. Many of your project's communications will lend themselves equally well to both methods. For example, if you communicate you can review your dashboard report with the project executive steering committee during a meeting, push it to the project team via an email broadcast, and archive it on a public directory or the project's website.

Lastly, remember that the accuracy of the information you communicate about the project will have a profound affect, either good or bad, on your reputation. You need to do your utmost to ensure the information you communicate is accurate. Measures such as the reconciliation between timesheets and your MS Project file can save you from making claims about project progress that aren't supported by the facts. Even with that degree of scrutiny your information can still be misleading or out of date. Be open and honest with your communications: tell your audience where the information comes from, how it was compiled, and how old it is. Be forthcoming with any information that could impact on the accuracy of your reports and let your audience form their own opinions of the accuracy and value of your communications.