Communication is a crucial result of any successful project and an important skill in project management. You may not have considered communication as an actual project product, but it is. It may not be the one your client or client puts the most emphasis on, but that’s because every client and client will take good communication for granted.
Project communication is an outcome for which you are personally responsible and it has a major impact on the success or failure of your project. I say this because personal experience has taught me that the best-run projects, delivering on all their promises, on time and on budget, can still get a bad reputation and be seen as failures. The reason: the project manager did not do enough work to communicate the success of the project to their stakeholders.
We hope the information and template in this section will help you choose the right information, planning, and communication tools for your project.
The main elements of project communication
Who to communicate with
You could just say it’s important to communicate with all project stakeholders and leave it at that, but this approach would guarantee failure. Each individual stakeholder has a different set of project information requirements and prefers different ways to receive their communications. It is not possible in most projects to define a unique set of communication and communication tools for each stakeholder, so the best thing to do is identify the different categories of stakeholders and define the required information and communication methods that work best fit the group.
Executive sponsor / corporate sponsor Probably the most important customer (s) of your project communication. It will be worth defining a custom set of communications for each person in this category. In general, these are busy people who don’t have much time to read a lot of details. Charts and graphs that tell the viewer a lot about the project at a glance 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 and how often. Keeping them updated on project performance is critical as they sign the check for the project (including your salary). They also need information to keep their colleagues up to date on the project’s performance. Remember that they are the champions of your project, so the more armed they are with information, the better they can promote your project.
Tip: do not report a problem to them without proposing a solution. For example, if you report an SPI less than 1.0 for the second week in a row, you must add a corrective action to the report.
Project team members This is the most populous group in your stakeholder list. You can divide the group into subgroups based on their roles. For example, you want 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 view of project performance than sponsors: the sponsor sees the project as work done for them. The team member views the project as work done by them and therefore project performance reports are a reflection on them. Everyone is satisfied with a good report: project sponsors and team members. A bad report will worry the sponsor, but can negatively impact the team’s morale.
Clients / clients These can be internal to your organization or outside of it. These people may not show any particular interest in project communication until the final product or service has been delivered. You must overcome this disinterest and arouse their interest in the progress of the project. The more informed they are about the project as it progresses through its life cycle, the more likely they are to accept the resulting products or services.
Partners These are people who do 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 program, or your projects may simply affect each other without further integration. For example, you manage a software project that requires a corresponding database project – the database project team is your partner. Or maybe you are working on a new software system for a software system that uses an existing web portal for customer access – the portal team is your partner even though they are not running a project.
Community stakeholders These are an increasingly important stakeholder category. As more emphasis is placed on the ethical behavior and social responsibility of organizations, there is an increasing demand for ethical projects. One of the ways this is done is by treating those who do not belong to the implementing organization or the client / client organization as stakeholders of the project. The focus on these stakeholders should go beyond communication, but project communication is 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 to the project. If you don’t receive the information you need to run the project, you can’t share it with other stakeholders. Your needs stem from the need to be kept informed of the progress of individual project tasks so that you can keep project plans up to date and identify preventive or corrective actions.
Project Management Office (PMO) Your PMO may have project information requirements that it can use to identify process improvement opportunities. While these needs are very similar to the needs of sponsors, clients, and clients to know how the project is progressing according to plan, the emphasis is on the project processes, tools, techniques, and best practices it supports. Your PMO may also be tasked with reporting project progress to the organization. Reports for which the PMO is responsible must contain very specific information requirements.
What to communicate
Which project information should be communicated to a stakeholder group is inextricably linked to the information 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 collecting the information is feasible, then you should do everything you can to make it available. The choice of the information to be communicated cannot be made without taking into account the project’s tools and techniques to collect the information and vice versa.
Project communication is not a main product of the project, but it should be treated as a project product. Start with your project charter: does the project charter contain information requirements? If so, the information and its target audience should be included in your communications management plan. Your Scope Statement may also contain requirements for project communication. The Statement of Work (SOW) may also include project communication requirements. When you are undertaking a project for an outside client or principal, the SOW is your bible and all project communications that are part of the legal contract must be itemized there.
After you have identified all the needs expressed in the project documentation so far, you should obtain requirements from the different stakeholder groups. This request must be made in the context of what is feasible to deliver the project. Be prepared to meet with your sponsor to determine their requirements. Be specific about the presentation: should the SPI (Schedule Performance Index) be displayed as a bar chart with a 6-week rolling figure? Should it be displayed as a line graph with the benchmark line of 1.0 and a 6 month moving figure? You may even want to mock some sample reports to get them to choose the format.
A project dashboard is a popular tool for communicating project progress to sponsors and other senior executives. The dashboard is intended to show the status of your project at a glance and can consist of the 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 cannot combine Schedule Drivers with Cost Drivers, but you can display Schedule Drivers and Cost Drivers in any combination that your sponsor desires. You may also want to include things like the top 5 risks, the top 5 outstanding issues, change statistics (number of change requests, number accepted, number declined, total cost, etc.), and quality (number of tests, number passed, number failed, open bug reports, etc.). You should try to keep your dashboard on a handful of slides and provide supporting details in text or Excel format as a backup.
You need to repeat the requirement gathering exercise with each stakeholder group, weighing their need for information against the project’s ability to collect and communicate it. Tip: share as much information as possible reported to the other groups with the project team (the people who actually do the work of the project). Your organization may have policies or guidelines about what can and cannot be shared outside of the executive offices; share as much information with the team as possible without violating this policy. You will find that sharing positive reports will boost morale, while sharing negative reports will stop rumors that will further erode morale.
Be prepared to record and report information by stakeholder group, department or sub-project. The individual groups on your team want to be able to see their progress separately from the rest of the team. Tip: make sure to split the work so that the tasks performed by individual groups or departments are recognizable. This allows you to report performance group by group or department by department and still report totals for the whole project.
The information you want to communicate will drive your activities throughout the project. Your plans should include the statistics to be collected to support the information you want to communicate. You must determine who is responsible for providing the information and from where the information should be stored and reported. There are two questions to ask yourself before making a commitment to provide a report:
1. How do I get this information? (i.e. what statistics should I record and where do they come from)
2. Where do I keep the statistics?
Failure to answer both questions means that you must either change your plan to instruct someone to collect the metric, identify a tool to capture and retrieve the metric, or drop the requirement.
Finally, don’t forget individual achievements and rewards when reporting project progress. There’s nothing like a good news story to keep team morale up and celebrating a team member’s achievement is something most sponsors love to hear about.
How to communicate
Many different means of communication are available to you – in person, email, intranet, internet, regular mail, telephone, video conferencing, etc., etc. These can be grouped into 2 groups: “push” communication and “pull” communication. Push communication requires you to push the information to the receiver as the name suggests, while pull communication requires the receiver to actively retrieve the information from a central source. Websites and centralized repositories are examples of pull communication, while email and meetings are examples of push communication.
The preference for push or pull communication is usually a personal preference. Some people handle information best when they get it, and some prefer to get it at their own leisure. 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 designate a group spokesperson who is authorized to identify the group’s requirements. The exception to this rule is the sponsor of your project. Since there are only one or two of these people, make sure that your communication methods fit their requirements.
Tip: If you determine that the project should have a new tool, such as a website, to meet stakeholder requirements, 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 replace your project. For example, a website or tool such as Lotus Notes can benefit all the projects your organization carries out, and can even provide an advantage for business operations. You may also want to investigate whether the PMO of Operations should bear the cost of the new tool.
When to communicate
Your communication schedule is determined by the needs of your audience and the availability of the information to be communicated. For example, if you have the bandwidth, you can report daily on all the statistics managed by your MS Project file. On the other hand, you cannot report on the results of your Gate Meeting until the Gate Meeting has actually taken place. There is also no reason that a report communicated to one stakeholder group every two weeks cannot be passed to another group every week.
In addition to documenting the requirements of your stakeholders, you should also use common sense. If you choose to use a “town hall” to communicate with all stakeholders, do not schedule the meeting weekly. Tip: When scheduling a meeting where you (or another team member) communicate information to an audience, count the audience, multiply that number by the number of hours the meeting lasts, and multiply that number by the taxed labor for that group. Don’t spend large sums on frequent communication.
Other meetings, such as status review meetings with project teams, should be held more frequently to avoid derailing the project. I feel that when the project is on track, weekly status review meetings are sufficient. If your project is having problems, you may 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 alternative way to identify completed tasks, don’t be afraid to cancel a status review meeting and give the team an hour off!
Remember that communication is part of the project work. You need to manage that work in your MS Project file like other project tasks, but be wise – don’t overburden yourself by keeping track of every meeting in MS Project. You should use the “walk around” style of management once your team is merged, you don’t have to keep track of every informal meeting with individual team members. Use MS Project to help you master the project, not overload yourself with work.
Tools and techniques
Tools and techniques include tools you will use to transfer the information, tools you will use to collect the information, and tools you will use to store and retrieve the information. Transportation tools include email, web sites, webcasts, conference calls, video conferencing, public directories, town hall meetings, and graphics tools such as Excel. What you communicate, how to communicate it and your communication budget determine which of these tools you will use.
There is one tool you 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 by most PMP exam preparation courses and in the PMBOK as Project Management Information Systems (PMIS). These tools are capable of capturing, manipulating and reporting most of the relevant information from your project, so you should be well acquainted with how to use them. There are many excellent courses available that will ground you in the fundamentals of using them.
Your organization can use a time registration system, in which case you have an additional source of information. Your time tracking tool should enable you to report labor costs for your project (i.e. support for billing time on your project code). It should also support reporting of these costs by group and by type of work. For example, it should tell you how much time was spent analyzing your software project last week. You need to match the time tracking system statistics with your MS Project file to make sure they are accurate. Tip: If your time tracking system is used to generate the pay slip for your team, make it your bible. A discrepancy means that your MS Project file may be inaccurate.
MS Project comes complete with a selection of “canned” reports, ready to use. I’ve found that the most useful feature for reporting project progress is the ability to export data to an Excel spreadsheet. Since Excel has been around for so long, it is feature-rich and supports almost any type of chart or chart you can think of. The trick here is to export the information you need to base your report on and then edit it in Excel. MS Project contains extensive auxiliary facilities for exporting data.
I mentioned the 2 different categories for dissemination of information: push and pull. Many of your project’s communications lend themselves equally well to either method. For example, if you are communicating, you can view your dashboard report in a meeting with the project lead control group, send it to the project team via an email broadcast, and archive it in a public directory or on the project website.
Finally, remember that the accuracy of the information you communicate about the project will have a major impact, be it good or bad, on your reputation. You must make every effort to ensure that the information you communicate is correct. Measures such as reconciliation between timesheets and your MS project file can save you from claims about project progress that are not supported by the facts. Even with that level of control, your information can still be misleading or out of date. Be open and honest in your communication: tell your audience where the information is coming from, how it is put together, and how old it is. Provide any information that could affect the accuracy of your reports and let your audience form their own opinion on the accuracy and value of your communications.