Plan and Manage Communication

Introduction

This lesson covers Task 1.8 of the People domain of the July 2026 PMP Examination Content Outline (ECO), a domain that carries 33% of the scored questions. Project managers spend most of their time communicating, and many project failures trace back to messages that were missing, late, unclear or sent to the wrong people. The ECO breaks the task into six enablers: define a communication strategy, promote transparency and collaboration (for example with information radiators), establish feedback loops, determine reporting requirements, create reports aligned with sponsor and stakeholder expectations, and define reporting and governance processes.

Lesson 4 identified the stakeholders and lesson 6 covered expectations. This lesson builds the system that carries information between them: what is communicated, to whom, how often, through which channel, with which feedback, and under which governance. The exam describes situations such as a distributed team with misunderstandings, a sponsor who receives reports that are too long, a stakeholder who feels uninformed, a message that was misread, or a dashboard that nobody trusts.

After this lesson you will be able to design a communication strategy, choose channels and methods, set up feedback loops and information radiators, define and tailor reporting, and connect reporting to governance.

Learning objectives

• Build a communication strategy from stakeholder needs, project context and constraints.
• Apply the communication model and the principles of effective communication, including barriers and noise.
• Select communication methods and channels suited to the message, audience and situation.
• Establish transparency and collaboration with information radiators and shared tools.
• Design feedback loops and check that messages are understood.
• Define reporting requirements and produce reports aligned with sponsor and stakeholder expectations, within reporting and governance processes.

1. Communication strategy and plan

A communication strategy states the overall approach to how the project will communicate; the communication management plan details it. A good strategy follows from the stakeholder analysis (lesson 4): the question is "who needs what information, when, in which form, and from whom?"

Inputs to consider:

• Stakeholder register, engagement needs and the influence and interest of each person.
• Project context: size, complexity, geography, time zones, languages, culture, regulatory or confidentiality limits.
• Development approach: a predictive project needs formal milestone and stage-gate reporting; an agile project uses frequent ceremonies and visible artefacts; a hybrid project combines them.
• Organisational policies, tools, templates and the communication assets of the organisation.
• Constraints: budget, available technology, security classification, contractual reporting obligations.

A typical plan contains, for each communication:

The plan is not frozen. It is reviewed when the stakeholders, the phase or the context change, and when feedback shows that communication is not working (too many emails, meetings with no decisions, people who are surprised by news).

Communication channels: counting paths

The number of communication channels increases quickly with the team size: n(n − 1) / 2. A team of 5 has 10 channels; a team of 10 has 45; a team of 20 has 190. If two people join a team of 8, the number goes from 28 to 45, an increase of 17 channels. This formula is a classic exam calculation and shows why larger projects need structure (leads, regular forums, shared tools).

2. Communication model and principles

A basic model has a sender, who encodes a message and sends it through a medium to a receiver, who decodes it and returns feedback. Noise (language, jargon, culture, distraction, poor connection, emotions, assumptions) can distort the message at every step.

Practical principles:

• Know the audience. Adapt vocabulary, level of detail and channel; executives need decisions and exceptions, teams need detail.
• Be clear and concise. One purpose per message, the key point first, a specific request and a date.
• Use several channels for important messages (a meeting followed by written confirmation).
• Confirm understanding. Ask the receiver to restate or answer questions; do not assume that "sent" means "understood".
• Listen actively. Give attention, paraphrase, ask open questions, note emotions as well as words.
• Consider culture and context. High-context cultures rely on tone, relationships and what is not said; low-context cultures expect explicit words. Titles, directness and time perception differ.
• Respect confidentiality and ethics. Do not disclose sensitive information to those who should not see it, and do not conceal facts that stakeholders have a right to know.
• Be consistent and timely. Predictable rhythm builds trust.

Methods of communication

Richness of channel. Face-to-face and video are richer (tone, body language, immediate feedback); written messages are less rich but leave a record. Sensitive or ambiguous matters belong in a conversation, then are confirmed in writing; routine data belong in written or automated reports.

3. Transparency and collaboration: information radiators

Transparency means that relevant information on progress, problems and decisions is available to those who need it without having to ask. In adaptive and hybrid projects it is a core value; in predictive projects it is supported by dashboards, regular reports and shared repositories.

An information radiator is a visible, regularly updated display of project information, such as a task board, a burndown chart, a risk board, a dashboard, a build-status screen or a wall of milestones. Good radiators have these qualities:

• Visible and easy to find, physically or online.
• Updated by the team in its normal work, not by a separate reporting effort.
• Simple enough to read at a glance and focused on a few indicators.
• Honest: they show problems, not only successes.

Collaboration is supported by shared workspaces, team spaces, joint planning, co-location or regular video contact, and working agreements about response times and channels. For distributed teams, add an overlapping time window, written decisions, recorded meetings, a glossary of terms, and attention to time zones and languages.

Example: a radiator that changes behaviour

A product team of nine builds a mobile banking app. Previously, the project manager sent a weekly status email that took half a day to prepare and that stakeholders rarely read. The team moves to an online board showing the backlog, the current iteration, blocked items in red, a burnup chart and the top five risks. Stakeholders can open it at any time, and a 15-minute weekly review replaces the email. Blocked items are visible the same day, and the sponsor sees a problem with a supplier API in two days instead of a week. Reporting effort drops from four hours to thirty minutes, and trust improves.

4. Feedback loops

A feedback loop is a mechanism that returns information about the effect of a communication or deliverable to the sender so that it can be adjusted. Without feedback, communication is one-way.

Examples of feedback loops in a project:

Techniques for checking understanding: ask recipients to summarise decisions, use confirmation emails ("Please reply if my summary is incorrect"), observe whether the expected action takes place, and ask a few stakeholders each month, "Do you receive the information you need, in a form you can use?"

If feedback shows a problem, the project manager adjusts the plan: fewer meetings, a shorter report, another channel, a different time, a translated summary.

Example: communication that was sent but not understood

A project manager emails a change in the release date to a supplier in another country using the phrase "we may need to table the delivery". In one version of English "table" means to postpone; in another it means to bring forward for discussion. The supplier hurries to deliver early. The next week a call establishes the misunderstanding. The project manager now writes dates explicitly, avoids idioms, and asks the supplier to confirm the new date in writing.

5. Reporting requirements

Reporting is the formal part of communication that tells stakeholders where the project stands. The ECO speaks about determining reporting requirements and creating reports aligned with sponsor and stakeholder expectations.

Steps to define the reporting requirements:

1. Identify who needs reports (sponsor, steering committee, PMO, customer, regulators, finance, suppliers).
2. Ask what decisions each audience takes and what they need to know for that purpose. A report without a decision or action behind it is probably unnecessary.
3. Check obligations: contractual, regulatory, organisational standards, funding conditions, audit requirements.
4. Define content, level of detail, format, frequency, owner and distribution, and the thresholds that trigger an exception report.
5. Agree with the sponsor and the key stakeholders, and record it in the communication management plan.
6. Review after the first cycles, and simplify.

Typical report content:

Aligning reports with the audience

Good reports are accurate, timely, consistent in format, honest and actionable. They show trends, not just snapshots, and they highlight exceptions ("management by exception"). Avoid "watermelon" reporting, in which the indicators are green outside but red inside because bad news is softened. Data should come from the same sources every time, and measures must be defined (what "80% complete" means).

Worked example: tailoring a report for a sponsor

Scenario. You manage an ERP rollout for a manufacturer with 12 countries. The sponsor, the COO, complains: "Your weekly report has 23 pages. I do not know whether I should worry." The steering committee also says that the status colours are inconsistent between work streams. Your PMO requires a standard template, and one regulator requires monthly evidence of data-protection controls.

Step 1 - Understand the need. Interview the COO: what decisions does she take (approve budget moves, resolve cross-country conflicts, inform the board)? She wants a half-page summary, top three risks, decisions needed, and an indication of whether the go-live date is at risk.

Step 2 - Separate audiences and obligations. Keep the detailed 23-page pack for work-stream leads (pull, on the portal). Create a one-page sponsor dashboard from the same data (push, weekly). Keep the PMO template as a monthly submission. Prepare the regulator's monthly evidence as a separate formal report with its own owner.

Step 3 - Define consistent measures. Agree a single definition of status colours: green = within tolerance (schedule variance under 5%, cost under 3%), amber = within the threshold but trending badly, red = tolerance exceeded and a decision is needed. Use the same measures in all work streams.

Step 4 - Test and review. Run the new report for three weeks, then ask the COO, "Do you have what you need?" Adjust one item (add a forecast of the go-live date with a confidence level).

Step 5 - Record the decision. Update the communication management plan and share it with the stakeholders.

Why not other choices? Sending an even longer report does not answer the question. Dropping the PMO template or the regulator's evidence would violate governance and compliance. Asking the sponsor to "read the full report" ignores her expectation. The best solution separates audiences, uses common definitions, and keeps all obligations met.

6. Reporting and governance processes

Reporting links to governance: the framework of authority, decision rights and oversight under which the project works (see Task 3.1 later in the course). Reporting and governance processes define:

• Who receives which report and who has the authority to act on it (sponsor, steering committee, change control board, PMO).
• Thresholds and escalation paths: variances beyond a defined tolerance (for example, cost or schedule outside 10%) are escalated within a given time to a specified level.
• Decision points and stage gates: what information is required before a phase continues.
• Approval, version control and records: who approves reports and formal communications, how they are stored and for how long.
• Audit and compliance: evidence that required reports were issued and decisions recorded.
• Information security and classification: who can see what, what channels can be used, retention and disposal.

In adaptive projects, governance often relies on the cadence of reviews, transparency of the backlog and metrics, and empowerment of the team within agreed boundaries, with the product owner and sponsor making decisions. In hybrid projects the governance combines stage gates with iteration reviews.

The project manager's responsibility is to follow the governance process, to make sure that escalation works (bad news reaches the right level quickly), and to propose improvements when reporting slows decisions or hides problems.

Example: an escalation path that works

A programme defines tolerances: the project manager can approve a schedule slip up to one week; between one and three weeks the programme manager decides; beyond three weeks the steering committee decides within five working days. When a supplier delay threatens a four-week slip, the project manager submits an exception report with causes, options (add a second supplier, reduce scope, accept the delay), and a recommendation. The steering committee meets within the agreed time and chooses to reduce scope. Because the path was agreed beforehand, no time was lost in debate about who should decide.

7. Common pitfalls and exam tips

Pitfalls

• Using one channel and one report for every audience.
• Sending more information, believing that more is better.
• Assuming that a message that was sent was understood.
• Producing reports that nobody reads or that lead to no decision.
• Hiding bad news, or reporting inconsistent status definitions.
• Relying on email for conflicts or sensitive topics.
• Ignoring time zones, language and culture in distributed teams.
• Treating the communication plan as fixed.
• Skipping the escalation path and informing stakeholders informally.

Exam tips

• The communication plan is based on the stakeholder analysis and updated as needs change.
• For complex or emotional topics, choose interactive communication; follow with written confirmation.
• Count channels with n(n − 1) / 2 and remember that adding people raises the number faster than linearly.
• Information radiators, dashboards and shared boards support transparency; the best answer often chooses a simple, visible, always-current display over a longer report.
• Ask what the audience needs to decide; tailor the report to that.
• When a stakeholder says they are not informed, the best action is usually to ask what they need and adjust the plan, not to send more of the same.
• Escalate according to the defined thresholds and path in the governance process.
• Honest and early communication of issues is always preferred.

8. Mini case study

Situation. You lead a 12-month programme to launch an online marketplace with a team of 22 people in three time zones (Europe, India and the US West Coast) and two external suppliers. The team uses email and a weekly one-hour video meeting with everyone. Recent problems: a design decision taken in the US was not seen in India for four days; two people produced conflicting versions of an API specification; the sponsor says, "I get lots of mails but no clear view"; a supplier says that it learned about a release delay from a third party. Team members say that they are in too many meetings.

Question. What do you do?

Model solution.

1. Analyse needs. Interview the sponsor, the supplier contacts and a sample of team members: who needs which information, for which decision, how often? Map the 22-person team: the channel count is 22 × 21 / 2 = 231, which shows why informal email cannot work.
2. Define the strategy. Structure the team into three or four sub-teams with leads, so that detailed communication is local and cross-team communication goes through defined forums. Choose an overlap window for the three time zones (for example 90 minutes) used only for decisions and cross-team questions; hold different sessions at different times by region where needed, with recordings.
3. Create transparency. Set up a shared online board and a decision log visible to everyone; a single repository with version control for the API specification; a glossary. Remove version conflicts by making one location the source of truth.
4. Replace the one-hour all-hands with: daily team stand-ups (local), a 30-minute cross-team sync twice a week during the overlap window, and a monthly all-hands for vision and feedback.
5. Report by audience. A one-page sponsor dashboard weekly (status, top risks, decisions needed, forecast), a steering committee pack monthly, a supplier channel with the shared release plan and notification of changes before they spread, and the PMO's standard metrics.
6. Set feedback loops. A short monthly survey ("Do you get the information you need?") and a communication retrospective every quarter; confirm key decisions in writing.
7. Define governance and escalation. Agree thresholds with the sponsor (for example, a delay of more than one week on a release is reported to the supplier and the sponsor within 24 hours).
8. Update the plan and review after two months using the survey and meeting data; remove what does not add value.

Key terms

• Communication management plan: the document that defines who receives which information, when, how and from whom.
• Sender, receiver, medium, noise, feedback: elements of the communication model.
• Push, pull, interactive: the three categories of communication methods.
• Information radiator: a visible, regularly updated display of project information.
• Feedback loop: a mechanism that returns the effect of a communication to the sender.
• Communication channels: n(n − 1) / 2 for n people.
• Management by exception: reporting that highlights variances beyond tolerance.
• Governance: the framework of authority, decision rights, oversight and reporting.
• Escalation path: the defined route and thresholds for passing matters to higher levels.

Summary checklist

• I base the communication strategy on stakeholder analysis, context and development approach, and keep it current.
• I use the communication model, check understanding and adapt to culture, language and noise.
• I choose interactive, push or pull methods according to complexity, sensitivity and audience.
• I use information radiators and shared tools for transparency and collaboration.
• I set feedback loops and adjust communication when feedback shows a problem.
• I define reporting requirements from the decisions each audience takes, and tailor concise, honest, consistent reports.
• I follow reporting and governance processes, thresholds and escalation paths.
• I can compute the number of communication channels.

Official sources

• PMI, PMP Examination Content Outline (July 2026), People domain, Task 1.8: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, New PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)