Project Communications: How to Keep Your Team Engaged and Informed
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 promise, 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
Sponsor/Business Sponsor Probably
the most important customer(s) of your project’s 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 apprised of the project’s performance. Remember, they are your
project’s 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 2ndweek 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 bythem 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
organization, 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 program, 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 software system new
software system that will utilize an existing web portal for customer access –
the portal team is your partner despite the fact they aren’t performing a
Stakeholders These are an
increasingly important category of stakeholder. As more emphasis is being
placed on organizations ethical behavior 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 organization,
or to the customer/client organization, 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.
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 to plan, 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 organization. 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
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 project 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
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 organization 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 rumors 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
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 2 questions
you need to ask yourself before you commit to providing a report:
do I get this information? (i.e. what metrics do I need to capture and where
will they come from)
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 metric, identify a tool
to capture and retrieve the metric, 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, e-mail, 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. Web sites and centralized 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.
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 web site, 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 web site or tool such as Lotus Notes could benefit
all projects your organization 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 labor rate for that group. Avoid spending large amounts on
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 e-mail,
web sites, web casts, 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 organization 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 labor 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 cheques 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 e-mail broadcast, and
archive it on a public directory or the project’s web site.
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 time
sheets 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.