Good communications are vital for successful projects. Just as the A.B.C. of sales stands for Always Be Closing (the deal), then the A.B.C. of project management stands for Always Be Communicating.
Junior project managers often think communicating is sending out a project status report.
However, this is not the case. The best project managers are constantly communicating, checking for understanding and then communicating some more. A partial list of items to express and share is shown below:
We do not need to memorize these items. Instead, we need to share a wide variety of information. A failure to communicate is a common cause for project failures.
Project Failures due to a Failure to Communicate
Many project failures can be traced back to communication failures. It could be the failure to communicate an issue in time, the failure to check an understanding, or confirm an agreement. Projects get behind one day at a time, and issues often start small and then compound. Communications can save the project if they occur in time and with the right people.
PMI research suggests communication breakdowns account for 30% of project failures. Some online discussions attribute 100% of project failures to communication failures. The variation in percentages stems from how we classify issues such as changing objectives or poorly articulated requirements. Some people classify them separately from communication failures, others as a type of communication breakdown. Either way, communication is a critical skill for any project manager.
Communication Management is a subset of Stakeholder Engagement
In Task 1.9 Collaborate with Stakeholders, we saw how collaboration is a subset of the Stakeholder Engagement Life Cycle. It looked like this:
This task, 2.2 Manage Communications, is also a subset of the Stakeholder Engagement Life Cycle that focuses on the Communications related components, as highlighted below:
Communications management starts with identifying the people we need to communicate with. Then determining what they need, planning the communications and the mediums to use. Then we can do the actual communicating and follow up to make sure the messages were received and interpreted correctly.
Types of Project Communication
Communication can be internal (with the project team) or external (outside of the team). It can be formal or informal, written or verbal. These types and some examples are shown below.
Within these communication types, there are more distinctions to be aware of.
- Hierarchical focus – Are we communicating up to senior management or with peers?
- Tone – The inflection used and the non-verbal gestures of body language.
2.2.1 Analyze Communication Needs of all Stakeholders
The first two steps of the Stakeholder Engagement Life Cycle are “Identify Stakeholders” and “Determine their Requirements.” As part of building our team and starting the project, we may have already undertaken some stakeholder analysis and created a Stakeholder Register.
Stakeholder Register
Stakeholder registers typically contain contact, interest and influence information for each stakeholder or stakeholder group identified. Here is an excerpt of the type of information they contain.
Agile projects may not create a formal stakeholder register. However, they likely have a Who’s-Who or contact information document, spreadsheet or Wiki page on the project site to record similar details.
Communication Requirements Analysis
Through interviews, questionnaires, workshops, and the study of lessons learned from previous projects, the process of communication requirements analysis determines the information needs of the project stakeholders.
The goal is to define a clear description of each stakeholders’ communications needs. It helps us choose the technologies, formats and frequencies for the project communications. It is the “Build Understanding” step before creating the Communications Management Plan.
2.2.2 Determine Communication Methods, Channels and Frequency
Determine the communication methods, channels, frequency, and level of detail for all stakeholders.
Some people prefer emails, others a website they can go to for information. Once we understand who we need to communicate with (via Stakeholder Analysis) and how they would like to be engaged (via Communication Requirements Analysis), we can now create the Communications Management Plan.
Communication Management Plan
The Communication Management Plan sets out to who, how and when we will share project information with various stakeholders. It can be a document or table on a website. The main thing is people know where to find it, and it explains how project information will be shared.
Components of a Communications Management Plan
Regardless of the format of the Communications Management Plan (formal document or webpage), it should consider the following communication attributes:
- A list of stakeholders and their communication preferences
- The information to be communicated
- The language or languages to be used, if more than one is being used
- Time frame and frequency of communications
- The person responsible for the communication
- Methods or tools used to convey the information
- Escalation process for issues that need visibility
- Glossary of common terminology
- Flowcharts of information flow
- Any communication constraints due to regulation or policies
Depending on the type of project you usually work on, this rigor and planning might all sound like overkill. However, for the exam, think about large projects with hundreds of stakeholders spread around the world. With this frame of reference, the need for a plan and details about exactly who gets what information and from where makes more sense.
Before crafting and sending project information, it is helpful to understand some theory about communications. It can help us avoid common pitfalls and explain why our communications go adrift.
Communication Models
There are several widely used models of communication that help us understand the process and challenges involved. Shannon and Weaver created a popular one called “The Mathematical Theory of Communication” that looks like this:
Suppose we wanted to announce that the opening of our petting zoo has been moved from Tuesday to Thursday because rain and strong winds are forecast for Tuesday. Using this model above, we represent the sender (1); we decide to send our message via email and announce “Opening delayed until Thursday for weather issues. Same activities and timing.”
The wording of the email is how we encode our thought (2). The medium of written text delivered via email is the signal we send over the channel (3). People receive the signal (our email) and decode it to extract meaning (4). From this process, the receiver interprets the message (5). They may provide feedback (that also gets encoded, transmitted and decoded).
Opportunities for Error
As we all know from dealing with people, just because we have a thought and try to convey it to others, that does not mean that thought will make it through the process intact. As an example, Tina, who uses a look-and-guess method of reading, sees “Opening delayed…” and she panics, stops reading any further and immediately assumes the entire project in jeopardy.
Marco, whose job is to make the big-top tent weather tolerant, sees this as an attempt to publicly shame his work. Jim has been too busy relocating frogs from the picnic site to read his emails recently, but he will have all the frogs moved by Tuesday.
These examples illustrate some possible outcomes and additional elements of the communications process. The words that we choose that have a single, clear meaning for us may be interpreted differently by others. Our communications also occur in an environment with noise and information loss. Finally, the sender’s and receiver’s context matters, as does their intent. These additional elements have been added to the image below:
The sender context (6) impacts the encoding and channel chosen, as too does the receiver context (7). The encoded signals are sent through channels with noise and a possibility for corruption or meaning loss (8).
Language can be imprecise, and the possibilities for misinterpretation are almost endless. A simple “How did you find the meeting?” question could be answered as 1) “Long and boring” or 2) “I looked up the room location on the floor plan and walked there past the cafeteria.”
Faults with encoding, channel choice and decoding are widespread. When we consider a large project environment with different cultures, generations, technical jargon, and acronyms with multiple meanings, it’s a wonder any messages get through as intended.
Guidelines to Improve Communications
- Prioritize: We can check our encoding and structure the message, so the most critical information is conveyed first. If we know the cause of the delay will be scrutinized, maybe we start with “Due to inclement weather, the opening is moved to…”. Also, assume not all of our communications will be read to the end, so move the critical information to the front in case people only scan it. Finally, having a strong or grabby Subject Line for emails and communications will increase the likelihood of our messages being opened.
- Choose your channel: Long lists of instructions are not best conveyed via a phone call. Text messages are great for on-the-go synchronization but may be too informal to send critical news to stakeholders you interact with infrequently. Delicate matters are best handled one-on-one in person or on the phone, where there is the opportunity for immediate Q&A.
- Get Graphical. Think about the type of information and message you are conveying and use the suitable medium. Consider visuals. Schedule information might be best shown with a timeline; geographic data with a map or floor plan.
- Don’t be afraid to duplicate and use multiple channels: Our brains are all wired differently, and we all have unique preferences for both format (sound, visual, written) and medium (F2F, email, video, project website). Typically, it is safer to over-communicate and send things in multiple formats via different channels to ensure the message gets through.
- Turn to technology: We live in a time of unprecedented information transmission and data-filtering technology. We have more tools and channels for communication now than ever before, yet things still get mixed up and missed out. While these tools can add to the sense of “overwhelm” and channel choice, they can also be used to create safety nets and save time.
2.2.3 Communicate Project Information and Updates Effectively
Throughout the project, project managers need to make relevant information available to stakeholders. This can be achieved through push communications, pull communications or a combination of the two. Let’s discuss the differences.
Push Communications
Push communications are reports, documents and messages pushed out (sent) to project stakeholders. Sending a project status report is an example of a push communication.
Pull Communications
With pull communications, people go to an information source such as a website and get the data they need. They pull the information they need. This can be from static reports, graphs and updates or in a more interactive way. Perhaps running queries, interacting with chatbots or downloading data for further analysis.
Hybrid and agile approaches encourage transparency and information sharing. Instead of sending status reports, meeting minutes and risk logs to stakeholders and hoping they are read, this information is publicly displayed in team spaces and on project websites.
Information Radiators
Information radiators are big visible charts that share project information. For instance, a task board and impediments board share much of the same information as a project status report (work done, work in progress, work planned, issues, etc.)
There are pros and cons to both sending reports and relying on information radiators. We could try to do both, but this might not be the best use of our organization’s time and money. Stakeholder analysis (asking what people want and need), whether conducted formally or informally, should inform our decisions.
Product Demonstrations – Show Don’t Tell
Sometimes the best way to explain what is going on is to show it. Rather than reporting on progress, hold a demonstration and show a product, solution or small chunk of one. Demonstrations are more concrete and tangible than a chart or report of progress. Any time we can see, touch and try something, we get a richer perception of it. Product demos are a great way to communicate project progress effectively.
2.2.4 Confirm Communication is Understood, and Feedback is Received
It is not sufficient to communicate and assume everyone understands our message and has their information needs completed. We should be checking in periodically with people to ask if the communications are working, if people have what they need, and how to improve.
Phase gates, steering committee meetings, demos and retrospectives are all good opportunities to inspect, learn and adapt our communications approach. We should ask if we are communicating enough, appropriately and successfully.
Communication management plans help define the sets of information, format and delivery frequency at the start of projects, but this is not a once-and-done process.
Mind the Gap
Once we realize there is a significant gap to overcome between getting a thought from our heads to those of others, we are halfway to building robust and reliable communication systems. We must not assume our messages will be opened, read, interpreted or regarded with the importance we assigned to them.
We need to communicate frequently, as a minimum, in the formats requested by stakeholders and using others too, if we want to be heard and understood. Technology can certainly help. We can create reminders to check in with key stakeholders. We can set up automatic forwarding of messages from platforms we do not like to ones we prefer to use. Tools can aggregate information from multiple sources and distribute messages to many recipients through numerous channels.
By mastering some essential communication tools, we can increase our coverage and free up time for thinking about how best to craft our messages with less chance of misinterpretation.
Deliverables and Tools
- Stakeholder Register
- Communications Management Plan
- Project Communications
- Information radiators
- Work performance and change updates
- Update project communications
- Stakeholder analysis
- Create and update Project Communications Plan
- Update documents
- Understand and apply Sender-Receiver Model
Related Topics
- 1.2 Lead a team
- 1.3 Support team performance
- 1.9 Collaborate with stakeholders
- 1.10 Build a shared understanding
- 1.11 Engage and support virtual teams
- 2.4 Engage stakeholders
- 2.10 Manage project changes
- 2.12 Manage project artifacts
- 2.15 Manage project issues
- 2.16 Ensure knowledge transfer for project continuity
Congratulations! You score 100% and won the 2.2 Manage Communications Badge.