{"id":1904,"date":"2020-03-19T16:20:35","date_gmt":"2020-03-19T14:20:35","guid":{"rendered":"https:\/\/djangostars.com\/blog\/?p=1904"},"modified":"2025-10-21T11:11:19","modified_gmt":"2025-10-21T11:11:19","slug":"project-management-communication-plan","status":"publish","type":"post","link":"https:\/\/djangostars.com\/blog\/project-management-communication-plan\/","title":{"rendered":"How to Create a Project Management Communication Plan"},"content":{"rendered":"

The software development process is complicated and, at times, chaotic. To make it less so, all its stages must be well-organized, planned, and agreed upon. Miscommunication, lack of clarity, and missed deadlines will jeopardize any project.<\/p>\n

The good news is, it is not usually that apocalyptic, as there is typically a project manager, whose function is to bring order to every step of the development process and document it in a communication plan. It prevents the aforementioned problems from occurring and helps predict the progress of the project as precisely as possible. A communication plan also eliminates misunderstanding during development, helps solve emerging issues in a timely manner, and shows stakeholders why you need the resources you requested. There are no downsides to a communication plan!<\/p>\n

But how do you create a communication plan that will work? Well, since practical experience is better than a textbook, we\u2019ll share how we do it at Django Stars.<\/p>\n

What is a project management communication plan?<\/h2>\n

First of all, let\u2019s start with the basics. Above all, communication is a process. And like any other process, it\u2019s supposed to be well-structured and, eventually, productive. Therefore, communication needs a strategy and a distinctive plan.<\/p>\n

What is a project communication plan, then? A project management communication plan is a set of criteria and an agreed order for holding and participating in communication events.<\/p>\n

If followed well, a communication plan for a project engages all teams and stakeholders in a well-organized process.<\/p><\/blockquote>\n

Like any other set of rules and regulations, it must be documented and accessible to everyone involved. However, there is no single right way to create a communication plan. It can be a checklist with planned meetings and events, or an online calendar with all the meetings scheduled accompanied by a Confluence board with all their rulers of the arrangement. Here at Django Stars, we stick to the latter, as Confluence and Google Calendar used together ensure there is no ambiguity in the rules.<\/p>\n

Apart from the schedule, the communication plan includes a list of documents, their format, and the dates when they need to be presented to the stakeholders.<\/p><\/blockquote>\n

The plan must be based on a mutually agreed upon and acknowledged schedule of meetings during a particular period of time, as well as the participants in each. All the members have to prepare the necessary data to share at the meeting for it to be constructive and productive.<\/p>\n

Why is a communication plan important in project management?<\/h2>\n

The main purpose of a well-structured Agile communication plan is evident: it\u2019s to make everything work. The Agile communication plan guides the team toward the development goal: namely, a complete and functional product. It helps to divide the communication plan creation process into understandable and manageable steps<\/strong>. As a means of achieving the final result, not only does the communication plan define the number and types of events and reports; it also specifies milestones. Every communication event marks a step in course of the development process and has a specific purpose, such as communicating important information to the client, reviewing the completed work, or planning next steps. The purpose of each communication event defines its participants, the people in charge, the meeting agenda, and the expected results. The project communication plan is a complex system that makes the development process comprehensible and effective for both the team and the client. For that reason, the project manager\u2019s function is to communicate on different levels. However, to assemble a thoughtful plan, the project manager must deconstruct that broader abstract goal and see every component of it.<\/p>\n

There are four key reasons why creating a sound communications plan is worth time and effort.
\n\"How<\/p>\n

It eliminates unnecessary communication<\/h3>\n

A communication management plan in project management will release the team from unnecessary work and save precious time. All unnecessary actions tend to slow down the work process. When every meeting and interaction within the team has a discussion topic and agenda, it reduces unnecessary and repetitive actions. Besides, when you have a distinct plan, it reduces the chance that important information about the development process will be missed.<\/p>\n

It builds better relationships<\/h3>\n

A communication plan schedules meetings where all team members can see the results of their work and understand the importance of everyone\u2019s contribution. The team works best when there is a healthy amount of trust among its members. To build that trust, they all must discuss what works well and needs to improve. When good trust relationships exist within the team, processes will run smoothly and problems are revealed before they become critical. The better the communication, the faster the team can acknowledge and solve problems. Failing to communicate problems is often graver than the problem itself.<\/p>\n

It enables more precise estimates for the next sprint<\/h3>\n

Such meetings allow teams to precisely estimate the time needed for tasks in the sprint based on the team’s velocity. They allow the team to discuss development approaches and agree on them. Meetings that include product owners shape the understanding of the goal the team has to achieve and helps the team figure out the optimal order of actions and the tasks needed to complete. In turn, retrospective meetings and reviews aim to clarify complications during the sprint and ways to manage them. The combination of these events helps the team achieve predictable results and adjust product updates.<\/p>\n

It leads to data for timely decision making<\/h3>\n

When a clear and well-organized system of meetings and reports is in place, the process of communication between the development team and product owners is optimized. This way, the participants can know the business aims and base their future tasks on the information they\u2019ve received and make planning decisions within this context. The system of reports and meetings give business and product owners a picture of the team\u2019s velocity and lets them know about the completion of product features and functions. It allows deadlines<\/a> and release dates for completed tasks to be set. Thus, transparent and timely communication allows both the business and the team to make informed decisions about their work.<\/p>\n

What the Project Management Communication Plan Defines & Solves<\/h2>\n

Essentially, a communication plan must answer four questions in terms of information delivery within the project: Who? What? When? How?
\n\"Four
\nOur Scrum communication plan is tightly related and based on the Scrum system, in which the team agrees on and commits to a certain number of tasks to complete within a sprint and the order of the communication sessions within it. If the team uses different frameworks, events and reports, their organization will be different. Therefore, the Scrum communication plan will not be the same. The project manager’s responsibility is to include communication in the spring adding Scrum events that are commonly meetings. The structure of communication events and reports is based on the methodology used and development approach. Nonetheless, it should be flexible enough to be improved and meet business needs.<\/p>\n

By answering the four questions above, the communication plan defines the rules of communication and interactions within the team. It schedules meetings, the number of participants, stakeholders reports, the discussion agenda, the form of communication (written or verbal, formal or informal), and the outtake for the team as a whole<\/strong>. For example, there are specific meetings with stakeholders to discuss what the team expects from them, and retrospective meetings held to review the team\u2019s performance in the previous sprint. Each type of meeting has a different aim, which is why the plan should define the number and type of participants and the matter to be discussed.<\/p>\n

Below, we will take a closer look at each type of meeting.<\/p>\n

Methods of communication<\/h2>\n

The methods of communication within each project depend on the project itself, the number of people on the team, and the deadlines the team is expected to meet. Before starting the work on the project, the team discusses the conditions of communication with the client and establishes the frequency of reports and their formats. Also, they define how to communicate urgent emerging problems and who participates in meetings must be agreed upon in advance. For example, not every meeting needs the whole team, so the roles in the meeting must also be discussed.<\/p>\n

The communication methods for each project are defined individually. Here we\u2019ll describe how we approach our effective project management communication plan at Django Stars.<\/p>\n

For us, a plan is based on the Scrum<\/a> system. Based on the framework, the set, number, order, and other features of meetings and reports may vary. The choice of the framework depends on the product and team’s needs. Apart from task management, it is convenient to create a project communication plan while keeping this in mind. The communication plan includes meetings, reports, and chat messages. Depending on the development approach, they can vary in frequency and organization. We will elaborate on each of them.<\/p>\n

Meetings<\/h3>\n

Every stage of the work progress is marked by a meeting with a different purpose and with different requirements for the team and the attendees. Meetings mark the checkpoints of the work performed, clarify all the questions, and allow the team to present to their accomplishments toward the big picture. In our development process, it looks like this:
\n\"Sprint<\/p>\n

Daily meeting<\/h4>\n

Also known as stand-ups, daily meetings are held for every team member so they can catch up on what\u2019s going on in the process. The attendees are all the team members. They discuss their current tasks, their progress, and what\u2019s limiting their work. If any technical issues emerge, they\u2019re discussed at a separate meeting.<\/p>\n

Pre-Refinement meeting<\/h4>\n

Attendees: Product Owner(s), Team Lead, and Project Manager<\/em>
\nThis meeting is held to clarify the plans for the next sprint. Each participant has their own role. The Project Owner outlines the business goals, and the Team Lead prepares the technical goals for future iterations. When all the expectations are presented and the goals for all the teams from the product perspective are clear, the result of the Pre-Refinement meeting is a high-level scope ready for grooming.
\nThe meeting is held at the beginning of the sprint and demonstrates its scope. At Django Stars, it is held bi-weekly.<\/p>\n

Feature Grooming<\/h4>\n

Attendees: The Feature Team, which includes team members working together on the same features. The members may vary, depending on the feature. Commonly it includes the BE engineer, FE engineer, QA engineer, and UI\/UX engineers.\u00a0<\/em>
\nThe aim of the meeting is to distribute the tasks that the feature requires, according to the competencies of the team members. The participants discuss the requirements for the end result (function or feature), and agree on execution approaches and integrations. It is a meeting for questioning the product owners to provide a single idea of what the result must be. Each grooming session is dedicated to a particular feature or story.<\/p>\n

Competency Grooming<\/h4>\n

Attendees: BE engineers, FE engineer, QA engineer, DevOps or UI\/UX engineers.\u00a0<\/em>
\nUnlike the feature grooming meeting, this one is meant to bring together teams according to their competencies. For example, BE engineers or only UI\/UX engineers will gather for this meeting. As teams gather in parallel, every competency unit discusses the tasks specific to them. The meeting\u2019s purpose is to groom the tasks \u2013 that is, to clarify everything that\u2019s unclear and discuss any questions that emerge about the tasks. As a result of the meeting, all the tasks must be estimated and assigned to team members. After that, the Project Manager will have a clear picture of how the team will complete the tasks within their scope. They can then discuss how to approach tasks in the upcoming sprint that require several competencies, according to the task estimates and the time each task requires.<\/p>\n

Planning<\/h4>\n

Attendees: All team members<\/em>
\nThe day before the current sprint ends or on the first day of the new one, the team meets up to commit to the scope of the next sprint. Essentially, the meeting provides an opportunity to plan the work for the following one. The team reviews the tasks to complete and, along with the product owner, decides what to include in the sprint, and what to leave for later. Based on the business needs, the product owner prioritizes tasks and the team decides how much they can manage to complete. Everything not included in the sprint goes to the Backlog. When the sprint scope is completed, the team writes a commitment letter for the sprint, which is the purpose and the result of this type of meeting.<\/p>\n

Later we will discuss the commitment letter in more detail.<\/p>\n

Sprint Review (Demo) meeting<\/h4>\n

Attendees: All team members<\/em>
\nThe Sprint Review happens on the last day of the current sprint. The project manager summarizes what\u2019s been accomplished during the sprint, and the team members present the features they worked on. The team reports on the ups and downs of the sprint to the product owner, who usually joins the meeting online. This is another reason why all the events should have a solid schedule: so everyone involved can synchronize with one another.<\/p>\n

Along with the team, the project manager assesses whether the spring was successful or not, based on the goals outlined in the sprint\u2019s commitment letter.
\nAfter the review, the project manager sends the sprint report and the tests report (written by the QA engineers) to the product owner. With these documents, the product owner makes a decision regarding the release (a go\/no-go decision).<\/p>\n

Sprint Retro meeting<\/h4>\n

Attendee: All team members<\/em>
\nAt this meeting, the team takes a retrospective look at the tasks completed in the previous sprint and compares the results to the tasks they committed to in the planning meeting. All the participants share the limitation factors they faced and if, how, and why anything went wrong.<\/p>\n

As a result of the meeting, the project manager creates an online board showing all the action points. Action points are the things the team needs to fix, including communication issues. When all the problems are identified and added to the board, the project manager assigns them to the team members who will fix them. All the problems in the sprint must be acknowledged and discussed at the demo meeting so the next sprint can be more productive and smooth. For example, if the problem was organizational and can be solved with a convenient filter in Jira, the project manager will assume the task. This meeting is the time to discuss any possible problems, even if someone needs a lamp, a mouse, or a new chair. The team describes the obstacles they faced during the sprint in order to reduce and prevent them from occurring in the future.
\n\"Methods
\nEssentially, all the meeting types are standardized in Scrum. At Django Stars, the only change we made has been to hold two separate grooming sessions. If your team is smaller, one grooming session for features and competencies should be enough.<\/p>\n

Scheduling meetings<\/h4>\n

Every meeting has its own place in the sprint. For example, if a sprint starts on Thursday and lasts two weeks, the Sprint Review and Sprint Retro will take place on Wednesdays, bi-weekly. Daily meetings must happen at the same time of the day, in the same location or room. The standard procedure for every meeting adds consistency to the work process. The agreed-upon time of every meeting is simply added to Google Calendar, so everyone involved can see it and keep up.
\n\"PM<\/p>\n

Meeting requirements<\/h4>\n

The procedure for every meeting must be transparent and accessible to all team members. At DjangoStars, we store all meeting requirements and rules in Confluence. It is clear to every participant what information they need to prepare before the meeting and what the expected outcome of each meeting will be. For example, the Planning meeting needs to meet the following criteria:<\/p>\n