What do you think is one of the most challenging aspects of running a project?
Well, for me, it's definitely project communication. As project managers, we all know how important communication is. It broadcasts project progress, statuses and very importantly - project risks and mitigation plans - to all concerned.
If you communicate consistently, stakeholders get updated and provide buy-in and potential project issues can be circumvented.
In this article, I'd like to introduce you to the project management communication plan.
I use this important tool upfront in a project, to determine who to communicate with (e.g. key stakeholders), when to communicate with them (e.g. daily, weekly, monthly) and how to do it (e.g. via face-to-face meetings, emails, newsletters).
Once you understand this toolkit and approach, you'll be much better equipped to keep your stakeholders informed of what's going on in your project.
Before we delve into the project management communication plan itself, let's try to understand what “project communication” is in the first place:
Definition: Project communication is the primary change management tool for any project and key to reinforcing desired behaviors. The overall objective of communication is to create a two way flow of information and to use the dialogue to channel efforts in the right direction until the objectives of the project have been achieved.
Sounds too technical? Well, another way of putting it is to say “Project communication is about delivering a clear and relevant message from one party to another so as to ensure project objectives are met”.
Notice the use of the words “clear” and “relevant” in the above sentence. It's absolutely important to be clear in your message so it gets understood. You should also ensure it's relevant - meaning, does the person need to know about what you're telling them? Or it's something they don't need to know about?
I find that many project managers I meet struggle with communication. It set me thinking why this might be so - and I conjecture a few reasons below:
If you're managing a large project, you could be faced with up to 20 or so stakeholders. That is a LOT of people to disseminate news, project updates and risks to. You won't have time to walk around and meet each stakeholder in person (although that's ideal) and if you make do with sending out email updates, people may not read them. So trying to communicate to a large number of stakeholders is inherently difficult to do.
The other thing that derails our project management communication plans? Tight project schedules. As a project manager, you're constantly assailed with tasks that require your attention. It is tough sometimes to clear your head and think about who needs to be updated, who should you discuss a project issue with, and so forth. There's so much chaos, you don't scan the horizon to see what is coming up and who to update.
Case Study: I was project manager of a large private banking system roll-out for an Southeast Asian bank. The project was to be delivered (front-to-back, all modules from client on-boarding / profiling, investment management, trade management, corporate actions) within six months, using a third-party software package. The six months timeline was absolutely crazy - so as you can imagine, things were “rushed through” - we could hardly get the requirements document, gap analysis, test scripts and deployment plans ready in time.
As you could imagine, that meant I didn't have time to think about my communication plan AT ALL. Everyday on the project was more of a fire fight, handling one emergency after another. That was a MISTAKE - because I ignore communications to my stakeholders, when it came time to sign off on requirements, testing and ultimately, go-live - most of the stakeholders resisted and didn't want to sign off.
In the end, the project was delayed for a YEAR. The lesson learnt is to always, always communicate to your stakeholders early and regularly throughout the project. Get their buy-in, they are the ones who pay your salary.
The truth is, many project managers (myself included) are not outgoing, flamboyant types. Many of us keep to ourselves and do not explicitly approach stakeholders to and update them on what's going on in projects.
Does it mean an introverted person cannot be a PM? Not really. You can do an introverted but make an excellent project manager if you install the correct methodologies and have requisite domain knowledge.
However, an introverted PM may slightly disadvantaged in terms of charisma and being able “grab the attention” of stakeholders. Communications do not come so naturally to them - hence the need for structured communication plans to ensure updates get delivered to key stakeholders.
Below is a screenshot of my project communication template, which you can download here. It's a simple. no-frills template which has helped me TREMENDOUSLY in many of my past projects. Once done up, you only need to review it say, every two weeks for updates.
My project communication plan template
Let's take a look at each of the columns in my template.
Date. Here I store the date of the communication going out to my stakeholder. Recording dates are important so that in your project calendar you know the specific times that a communication email or meeting should occur.
Stakeholder Name. I find that many, many project managers don't write down a list of their stakeholders. I think this is fine if you're running a small project, but for large projects, knowing WHO your stakeholders are is absolutely critical. Your stakeholders determine whether your deliverables are signed off and hence whether you are paid for your project management work. So please, know who they are!
Stakeholder Title. This is simply an additional field to the Stakeholder Name. I'd put, for example, titles like “CEO”, “CIO”, “Head of Products”.Information Required By Stakeholder. Another key field that MUST be determined by you, the project manager. You don't have to record extremely detailed information - doing that will just clutter up the template. I prefer to record things like “Project status update”, or “Items requiring management decision”. Timing / Frequency. Are you going to send out an email or have a face-to-face meeting on an adhoc basis? Or a weekly or monthly basis? Specify that here. Things like Project Steering Committee meetings (i.e. meetings where a bunch of senior management folks come together trying to look like they “know” what's going on in a project when they actually don't) - are usually done on a monthly basis.
Delivery Channel(s). This column is to record how you're delivering information to your stakeholder (e.g. sending an email, sending a newsletter or having a face-to-face meeting). Sometimes, as project managers, we don' sit down to think of these matters.
That's where a communications plan is important. It makes explicit many of the decisions we would otherwise have to waste time thinking about. With a communications plan, I don't have to think - I just KNOW that when a certain date comes, this email has to go out, or that meeting has to take place - and my required communications to key stakeholders will be taken care of.
Team Owner. In your team, who is the person responsible for crafting the information update to the stakeholder? Perhaps it's you, the project manager. Perhaps it's your lead business analyst or test manager. Make sure you indicate clear ownership so it's clear who does what.
Comments. I've also got a “Comments” column to store miscellaneous remarks about the piece of information published to the stakeholder. I use it to indicate key pieces of information that are useful for me to know. For example, comments could be something like “Mr XXX was not to happy to hear about YYY”, or “Critical to deliver message that project will be delayed”.
Case Study: I used to send out my project status updates in email format. A lot of project managers do that (especially those who are more introverted and don't like face-to-face meetings). To me, this is BAD. As a project manager, you should be “out there” as much as possible, talking to your stakeholders - everyday, if possible.
I'm not saying email status updates are not good, but you should use them for “broadcast” type of communication which everyone needs to know (e.g. “We've managed to set up the test environment and here are the login credentials). However, things like project issues or in-depth discussions should always be kept OUT of emails and discussed in person where possible. It demonstrates to your stakeholders that you're taking the issue seriously and not just relegating the problem to an “email discussion”.
I've not talked about why a project management communication plan is advantageous. Why not let things just run adhoc? When you feel like it, send an email. If you don't feel like it, discuss stuff face-to-face. Isn't it easier that way? Well, I disagree. I think having a formal communication plan is useful for the following reasons.
I've talked about forgetting to send out communications to stakeholders because you're just so busy you don't have to think about it. It's a bit like writing your daily to-do tasks down. If you don't get them down in writing, they tend to just “float” in your head, with a high chance of being ignored. Externalize your communication schedule in writing and you'll start see a tendency for yourself to start adhering to the schedule.
I never did think of this aspect before, but how often do you find yourself just “communicating” to someone without thinking about the “structure” of the communication? For example, is it useful for you to send an email summarizing key discussion points, THEN follow up with a face-to-face discussion with a person? I think it's VERY useful.
Case Study: I once had to convince a senior stakeholder to accept a workaround solution in the software we were rolling out. The software could not be configured to store a list of client prospects within the project timeline.
I wanted to suggest to this stakeholder that the system users maintain prospects in Excel files for an interim period after go-live. This would inconvenience the users, but at least buy some time for the system to be configured with that capability, e.g. within two months after go-live.
Sensing it would be a tough discussion, I sent an email to this stakeholder explaining why the manual prospect file would need to be maintained. At the end of the email, I mentioned that “I'd like to discuss the above with you and agree on the approach.”
Then I quickly follow up with a face-to-face meeting, using that email I sent as a basis for discussion. This set the context for the discussion and allowed us to have a very fruitful discussion on the workaround (which got signed off and accepted by the way).
In many companies, “project governance” is a must. There are entire departments in a bank dedicated to “Project Quality and Assurance” or “Project Standards”. It's a hot topic and I think it's probably something invented by some over zealous PMO person who want to put more “value add” into the PMO's realm of responsibilities.
I think that project governance is not required especially for smaller projects. If I'm doing a four week project to determine what core system to select for a bank, do I really need “project governance” installed? I don't think so. But if I'm running a two year long core banking system replacement project - then heck yes, project standards are very useful.
To tie this back to the project communications plan, you should know that having this plan (and other project management templates) goes a long way into “demonstrating” that you have at least some sort of project standards in place - you'll then be able to stand up to scrutiny if some audit guy comes “check on” your project.
Now, who should make use of the project management communication template? In my opinion, the heaviest user of the template should be YOU, the project manager.
The next most common user of the communication plan is the Change Manager. In large projects, there is usually a Change Manager to handle change and training. This person makes sure the users are “readied” for the new business processes that will kick in once the new system goes live.
You can imagine that a LOT of communication goes into change management. Usually, tools like newsletters, email updates and training workshops need to be scheduled. And the communication needs to be controlled and monitored.
Can you imagine a Change Manager sending out an email that has no relevance to the users, or perhaps or repeatedly sends an email he or she has sent before, or worse - sending an irrelevant email to the WHOLE company? You've seen some of those happening in your workplace, I'm sure!
I'd like to put down a note on WHEN you should draw up your project communication plan.
In a word, the plan should be drawn up BEFORE THE START of your project. It's best discussed as part of the “Method Adoption Workshop” (which I've touched on here), at the point when you're deciding which templates and approaches you'll adopt for your project.
The reason for doing it at the start is so that your project communication starts being regular and consistent as soon as possible. If you wait till the end of the project before you put in structured communications, stakeholders may already be “too lost” to listen to you. So communicate early and regularly, in a structured manner.
Oh, and some last thoughts on project communications which is useful to mention here at the tail-end of this article.
When you're communicating messages to your project stakeholders, please, please remember to think of WHAT YOUR AUDIENCE needs to know. I've seen so many project managers sending two to three page emails explaining project progress.
Guess what happens to those emails? Yes, they don't get read. They just get thrashed or forgotten. Please always tailor your communication to what you believe the reader wants to know about. Then provide succinct and clear messages, instead of writing half a novel describing every single detail.
I've touched on this briefly, but it's worth mentioning again, since it is SUCH a useful tool. This tip means that I convey the same message (e.g. Workaround ABC is critical if we want the project to go-live by Date X) using different communication modes (e.g. email, face-to-face, newsletters).
I find this very useful if I'm trying to remind, or more importantly - persuade - someone to see my recommendation. If you email then speak to someone about a project issue, he or she will be more receptive as they have heard your message twice. If you just do it over email, it's bound to be less effective.
Another critical element of project communications is your ability to listen. If you simply push out messages to stakeholders and ignore their feedback - you're not showing empathy to your stakeholders. And that is a risky thing to do, especially if you're dependent on them for a final sign-off.
If stakeholders have feedback on what you've communicated, do a FOLLOW-UP. Address any concerns if they are valid or send an email that you'll look into it by a specific date. The last thing you want to do is to IGNORE the feedback - that destroys your credibility very quickly.
I hope the above has given you a solid idea of the project management communication plan - why you need it, how and when to use it. Some project managers (especially long-time veterans) see this as just “documentation” and tend to gloss over it.
I think the opposite - a project communications plan allows you to engage your stakeholders in a structured manner to meet project objectives. It even allows you to subtly “persuade” stakeholders too (by delivering consistent messages through different channels).
All in all, communication is a “must-do” item in any PM's checklist - so make sure you learn and apply the above tips in your next project. Hopefully, you'll find your stakeholders easier to manage!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.