Key Concepts

The ABC of project management is Always Be Communicating, and it takes a deliberate plan rather than good intentions. A communication strategy sets the frame for who gets what, when, and how, and should reflect the project, its stakeholders, and the organization. That strategy becomes the communication plan: a living document naming the communication channels, cadence, and owners for each audience. PMI research attributes about 30% of project failures to communication breakdowns.

AI Banner 3
Plan and manage communication
album-art
00:00
"The single biggest problem in communication is the illusion that it has taken place."
George Bernard Shaw
George Bernard Shaw
Nobel Prize winner for literature

Good communications are vital for successful projects. Just as the A.B.C. of sales stands for Always Be Closing, the A.B.C. of project management stands for Always Be Communicating.

Junior project managers often think communicating means sending out a project status report. 

Limited View of Communications

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:

Mindmap of communication types

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.

Failures

Project Failures due to a Failure to Communicate

PMI research suggests communication breakdowns account for around 30% of project failures. Some discussions attribute even more failures to communication breakdowns, depending on how we classify problems such as changing objectives or poorly articulated requirements. Either way, communication is one of the most critical skills a project manager can develop, and it requires a deliberate plan rather than good intentions.

In section 1.4.3 we covered how to tailor communication to individual stakeholder needs, including push, pull, and interactive communication types, and the use of Communication Styles Assessments. This section focuses on the broader discipline: defining a communication strategy, building transparency, establishing feedback loops, and ensuring that reporting and governance needs are met systematically throughout the project.

1.8.1 Define a Communication Strategy

Illustration for 1.8.1 Define a communication strategy
(Plan who needs what information, when, and how)

A communication strategy is the overall approach a project will take to sharing information with its stakeholders. It sets the frame before the details of who gets what, when, and how are worked out. The strategy should reflect the nature of the project, the stakeholder landscape, the organizational culture, and the development approach being used. A one-size-fits-all communication strategy rarely fits anyone particularly well.

Defining the strategy begins with understanding the communication environment. This includes the types of communication the project will rely on, such as verbal, written, and behavioral, and the channels available to the team. It also means being aware of cultural and language differences, formality requirements, data protection regulations, and accessibility needs that may shape how information can and should be shared.

Kickoff Meeting

The Kickoff Meeting

The kickoff meeting is one of the first and most important communication events on any project. It establishes the communication tone and expectations from the start, and it should be planned as carefully as any other project event.

Two types of kickoff meeting often serve different purposes on a project. An internal team kickoff, held after agreements are finalized, focuses on establishing the project’s context and giving an overview of the project charter. It also assists in team formation, clarifies roles and responsibilities, aligns the team on the project vision, and presents the results of planning efforts. An organizational or public kickoff serves a different purpose. It announces the project’s initiation, shares the high-level vision and value, and identifies the sponsor and project manager. For agile projects, it also initiates the product backlog and presents the product roadmap.

Where possible, both purposes are worth serving, though sometimes they are combined into a single session. The important thing is that all key stakeholders leave the kickoff with a clear picture of why the project exists, how it will be run, and how they will be kept informed.

Communications Management Plan

The Communications Management Plan sets out who will receive project information, how, and when. It can be a formal document or a table on a project website. The main thing is that people know where to find it and that it explains how project information will be shared.

Regardless of its format, a Communications Management Plan should address the following:

  • A list of stakeholders and their communication preferences
  • The information to be communicated
  • The language to be used, if more than one is in play
  • Time frame and frequency of communications
  • The person responsible for each communication
  • Methods or tools used to convey the information
  • Escalation process for issues that need visibility
  • Glossary of common terminology
  • Any communication constraints due to regulation or policy
Communications Plan sample

For smaller projects this level of detail may feel like overkill. For the exam, picture a large project with hundreds of stakeholders spread around the world. At that scale, the need for a plan that defines exactly who gets what information, and from where, becomes obvious.

Communication expectations should also be included in the team charter, so the team’s own norms for how they communicate internally are captured alongside the broader stakeholder plan. The charter records agreements on meeting times, preferred tools, response expectations, and how the team will handle internal disagreements, all of which affect how well communications flow.

Traditional Icon

On predictive projects, the Communications Management Plan is typically produced during the planning phase and baselined alongside other subsidiary plans. It is reviewed at phase gates and updated when significant changes occur to the stakeholder landscape or project scope. Communication is largely managed through scheduled reporting cycles, structured status meetings, and planned milestone reviews.

Agile icon

Agile projects replace a formal communications plan with communication events built into the delivery cadence. Demos, daily stand-ups, retrospectives, and information radiators serve the functions that a communications plan describes on a predictive project. The product roadmap and backlog act as living communication artifacts, always reflecting the current state of priorities and planned work

1.8.2 Promote Transparency and Collaboration

Illustration for 1.8.2 Promote transparency and collaboration
(Make information visible and accessible to everyone)

Transparency means making relevant project information visible and accessible to those who need it, without waiting to be asked. It is one of the most effective tools a project manager has for building trust, surfacing problems early, and keeping stakeholders engaged. People who feel informed tend to stay supportive. People who feel information is being managed or filtered tend to become suspicious and disengaged.

Promoting transparency is not simply about publishing more information. It is about making the right information available in the right form, and creating a culture in which people feel safe sharing what they know, including bad news. Do not communicate good news while quietly managing bad news. Stakeholders are astute, and they notice the gap between project communications and the reality they observe on the ground.

Information Radiator

Information Radiators

Information radiators are large visible charts, boards, or displays that share project information broadly and continuously. Rather than sending reports that may or may not be read, information radiators make the project’s status, tasks, risks, and issues visible to anyone who looks. Task boards, burndown charts, impediment boards, and release plans are all forms of information radiator.

The agile principle of transparency promotes open and honest sharing of information to raise everyone’s awareness of work, progress, and issues. Information radiators are the primary mechanism for delivering on that principle. Information radiators are maintained by the team rather than by the project manager, which broadens the set of people who feel a stake in communicating project status.

Information radiators can be physical, such as charts on the wall of a team room, or digital, displayed on shared project websites and dashboards. Digital radiators make information accessible to distributed teams, though their pull nature means stakeholders must seek out the information rather than having it placed in front of them. Both formats have a role, and many projects use both.

Information Radiator

Collaboration Practices

Transparency creates the conditions for collaboration, but collaboration requires more than available information. It requires people to feel comfortable contributing, questioning, and building on each other’s ideas. The project manager plays an active role in creating this environment by facilitating rather than directing and by asking questions rather than providing all the answers. Making it clear that challenge and debate are welcome, rather than threatening, is equally important.

Practical steps to promote collaboration include creating shared workspaces where work and progress are visible, and scheduling regular forums where team members and stakeholders can surface issues before they escalate. Decisions should be made by the people closest to the relevant information rather than by default at the top of the hierarchy.

1.8.3 Establish a Feedback Loop

Illustration for 1.8.3 Establish a feedback loop
(Send message, confirm receipt, adjust based on feedback)
"Don't forget that feedback is one of the essential elements of good communication."
Anonymous
Anonymous
Unknown/shy person

Communicating is not enough on its own. We also need to confirm that what was communicated was received, understood, and interpreted correctly. The communication model described by Shannon and Weaver explains why feedback matters. A message passes from sender through a channel to a receiver, and at each step there are opportunities for noise, distortion, and misinterpretation. By the time a message arrives, it may bear only a passing resemblance to what was intended. The only way to know whether it got through as intended is to ask.

Comm model Part 1

Example: 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).

Errors

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:

Comm model Part 2

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.

It is not sufficient to communicate and assume everyone understood the message and has what they need. We should be checking in periodically to ask whether communications are working, whether people have what they need, and how things could improve. Phase gates, steering committee meetings, demos, and retrospectives are all structured opportunities to do this. We should be asking whether we are communicating enough, in the right formats, and whether the information is being used as intended.

Smart icon

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.
Active Listening

Active Listening

Active listening is a communication technique that involves being attentive and participatory when engaging with another individual. It includes repeating or rephrasing what the speaker said in your own words to confirm understanding, using nonverbal cues to show engagement, and asking for clarification or expansion when needed. It is the difference between waiting for your turn to speak and genuinely seeking to understand what the other person means.

Active Listening

Active listening is as relevant in feedback conversations as in initial requirements gathering. When a stakeholder provides feedback on a status report or a deliverable, the impulse to defend or explain can get in the way of actually hearing what they are saying. Listening fully, reflecting back what you heard, and checking your understanding before responding produces much better outcomes than responding to the feedback you expected rather than the feedback you received.

Close the feedback loop

Closing the Loop

Feedback loops must be closed, not just opened. Asking for feedback and then not acting on it, or not communicating what was done in response, is worse than not asking at all. People quickly learn that their input disappears into a void, and they stop providing it. When feedback leads to a change, communicate that change and attribute it to the feedback. When it does not, explain why. Both responses demonstrate that the feedback was genuinely considered, which encourages people to keep sharing.

Communication management plans define the sets of information, formats, and delivery frequencies at the start of projects. The feedback loop is how we verify that those plans are actually working and adapt them when they are not. Do not treat the plan as the goal. The goal is stakeholders who are informed, aligned, and engaged. The plan is just the starting point for getting there.

1.8.4 Understand Reporting Requirements

Illustration for 1.8.4 Understand reporting requirements
(Ask each stakeholder what they need to know and when)

Project reporting requirements are the foundation for ensuring effective communication, decision-making, and problem resolution throughout the project. Before creating any reports, we need to understand what governance bodies, sponsors, and stakeholders actually need. That understanding requires a conversation, not an assumption.

When establishing reporting requirements, focus on three dimensions:

  1. Content
  2. Format
  3. Frequency
Report Requirement Dimensions

Content: What information do stakeholders need in order to make decisions, identify problems, and assess project health? Key content areas typically include schedule status, cost performance, scope changes, risk and issue updates, and any corrective actions underway. Different stakeholder groups need different content: a sponsor needs strategic indicators, a technical lead needs operational detail, and a governance board needs exception reporting.

Format: How do stakeholders prefer to receive information? Some want simple one-page summaries with traffic-light indicators, while others want detailed data they can interrogate themselves. Some prefer information presented in meetings with opportunity for discussion, while others want to read and respond asynchronously. The Communication Styles Assessment covered in 1.4.3 directly informs these choices.

Frequency: How often do stakeholders need updates to remain appropriately informed? Frequency should be driven by the pace of change on the project and the decision-making cadence of the stakeholder, not by the convenience of the project team. A weekly status report may be appropriate for a slow-moving infrastructure project, but inadequate for a fast-moving agile delivery where the picture changes daily.

Reporting requirements should be documented and agreed upon with key stakeholders early in the project, then revisited as the project evolves. What works in the planning phase may not serve well during peak execution or as the project moves toward closure.

Communication Methods

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.

Types of communication

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.

1.8.5 Create Reports Aligned with Sponsors and Stakeholder Expectations

Illustration for 1.8.5 Create reports aligned with sponsors and stakeholder expectations
(Tailor the message format to fit each audience)

Understanding what is required is only half the job. The other half is producing reports that are genuinely useful, not just technically compliant with what was asked for. A report that is complete and accurate but presented in a format no one can quickly read is a poor communication tool. A report that is easy to scan and highlights the things decision-makers care about is a good one.

Good project reports share some common characteristics. They put the most critical information first, because not everyone reads to the end. They distinguish between status (where things stand today) and trend (whether things are getting better or worse), because trend is often more useful to decision-makers than a snapshot. They flag exceptions, the things that are off-track or at risk, rather than burying them in a wall of green indicators. They also use visuals where visuals communicate more clearly than prose. Schedule timelines, cost trend lines, risk heat maps, and burndown charts all convey information more efficiently than their narrative equivalents.

PMIS

Project Management Information System

A Project Management Information System (PMIS) gathers, integrates, and shares project data to help ensure consistency in collection and reporting. Commercial project management platforms give stakeholders access to consistent, current project information without requiring the project manager to manually produce and distribute it.

A PMIS makes information available on demand rather than on a schedule, which suits stakeholders who want to check on specific aspects of the project between formal reporting cycles. It also creates a single source of truth, reducing the risk of different stakeholders operating from different versions of the project picture.

Artifact Management Systems

Artifact management systems store and maintain project documents, plans, and other records in a controlled, accessible format. Tools such as SharePoint, Teams, and Google Drive serve this function for many organizations. They support version control, access management, and the kind of audit trail that governance and compliance requirements often demand. Any documentation, plan, or item that could reconstruct the history of the project should be maintained and archived in a system that preserves that history reliably. This is especially important where changes were made and decisions need to be traceable.

Agile icon

Agile projects minimize formal reports and maximize visible, real-time information. The product backlog, sprint board, and burndown chart serve as the primary reporting artifacts, available to stakeholders continuously rather than delivered on a schedule. Sprint reviews provide a regular cadence for structured reporting to sponsors and business stakeholders, combining a demonstration of working output with an update on progress, risks, and upcoming priorities.

1.8.6 Support Reporting and Governance Processes

Illustration for 1.8.6 Support reporting and governance processes
(Publish the process and adjust as needed)

Project communication does not exist in isolation. It operates within an organizational governance framework that defines what needs to be reported, to whom, at what frequency, and in what format. Supporting governance processes means understanding that framework and aligning the project’s communication activities with it. Treating governance reporting as a separate overhead to be managed around the real work is a mistake.

The key principles for supporting governance effectively are straightforward. Be proactive: bring information to governance bodies rather than waiting to be asked. Be transparent: share honest and consistent updates including variances, risks, and recovery plans, not just the good news. Be timely: governance bodies make decisions based on the information they have, and late or incomplete information produces late or poor decisions.

Phase Gate

Phase Gate Reviews

Phase gate reviews, also known as governance gates, kill points, or tollgates, are formal checkpoints where a project’s progress is assessed and a go/no-go decision is made. They are one of the primary mechanisms through which governance is exercised on predictive projects, and they represent significant communication events that require careful preparation.

At a phase gate, the project team presents evidence that the deliverables of the completed phase meet the agreed criteria. They also propose the plan and rationale for proceeding to the next phase. The governance body reviews this evidence and makes its decision. A well-prepared phase gate presentation gives decision-makers what they need clearly and concisely, addresses likely concerns proactively, and does not leave critical information for them to discover on their own.

Escalate Issue

Escalation

Part of supporting governance is knowing when to escalate. Problems that are within the project’s defined tolerances can be handled at the project level. Problems that breach those tolerances, or that require a decision beyond the project manager’s authority, must be escalated promptly. Waiting too long to escalate in the hope that the problem will resolve itself is one of the most common and costly mistakes in project management. Governance bodies cannot help with problems they do not know about.

Governance reporting should also ensure traceability: that the reasoning behind key decisions is documented, that change requests are tracked, and that the project’s audit trail is maintained. These records protect the project manager as much as they serve the organization, and they enable future projects to learn from what this one experienced.

Communication, done well, is the connective tissue of a project. It holds the plan to the execution, the team to the stakeholders, and the project to the organization. Everything else covered in the People domain, from building shared vision and managing conflict, to leading the team, engaging stakeholders, aligning expectations, and transferring knowledge, depends on communication working effectively. A project manager who communicates well can compensate for many other challenges. One who does not will struggle regardless of how sound the plan is.

Deliverables and Tools

  • Communications Management Plan
  • Team Charter (communication norms section)
  • Kickoff Meeting (internal and organizational)
  • PMIS (Project Management Information System)
  • Artifact Management Systems
  • Information Radiators
  • Phase Gate Reviews
  • Active Listening
  • Communication Styles Assessment
  • Shannon and Weaver Communication Model
  • Status reports
  • Dashboards and visualization tools
  • Product roadmap (agile)
  • Sprint board and burndown chart (agile)

Related Topics

FAQ

Is communication just sending status reports?

No. The best project managers communicate constantly, check for understanding, and keep going; status reports are only a small part.

What is a communication strategy?

The overall approach a project takes to sharing information with its stakeholders, set before the details of who gets what, when, and how are worked out.

What is the kickoff meeting for?

It establishes the communication tone and expectations from the start; an internal team kickoff and an organizational kickoff serve different purposes.

How much do communication failures cost projects?

PMI research suggests communication breakdowns account for about 30% of project failures.

How does this task fit into the 2026 PMP exam?

Task 1.8 sits in the People domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.

Mastery Map and Quiz

Quiz Icon