How to Create a Project Management Communication Plan

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.

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!

But how do you create a communication plan that will work? Well, since practical experience is better than a textbook, we’ll share how we do it at Django Stars.

What is a project management communication plan?

First of all, let’s start with the basics. Above all, communication is a process. And like any other process, it’s supposed to be well-structured and, eventually, productive. Therefore, communication needs a strategy and a distinctive plan.

What is a communication plan, then? A communication plan is a set of criteria and an agreed order for holding and participating in communication events.

If followed well, a communication plan engages all teams and stakeholders in a well-organized process.

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.

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.

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.

Why is a communication plan important in project management?

The main purpose of a well-structured communication plan is evident: it’s to make everything work. The 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. 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 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’s 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.

There are four key reasons why creating a sound communications plan is worth time and effort.

It eliminates unnecessary communication

A communication plan 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.

It builds better relationships

A communication plan schedules meetings where all team members can see the results of their work and understand the importance of everyone’s 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.

It enables more precise estimates for the next sprint

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.

It leads to data for timely decision making

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’ve received and make planning decisions within this context. The system of reports and meetings give business and product owners a picture of the team’s velocity and lets them know about the completion of product features and functions. It allows deadlines 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.

What the Project Management Communication Plan Defines & Solves

Essentially, a communication plan must answer four questions in terms of information delivery within the project: Who? What? When? How?

Our 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 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.

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. For example, there are specific meetings with stakeholders to discuss what the team expects from them, and retrospective meetings held to review the team’s 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.

Below, we will take a closer look at each type of meeting.

Methods of communication

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.

The communication methods for each project are defined individually. Here we’ll describe how we approach our communication plan at Django Stars.

For us, a plan is based on the Scrum 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 the 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.

Meetings

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:

Daily meeting

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

Pre-Refinement meeting

Attendees: Product Owner(s), Team Lead, and Project Manager

This 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.

The meeting is held at the beginning of the sprint and demonstrates its scope. At Django Stars, it is held bi-weekly.

Feature Grooming

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.

The 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.

Competency Grooming

Attendees: BE engineers, FE engineer, QA engineer, DevOps or UI/UX engineers.

Unlike 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’s purpose is to groom the tasks – that is, to clarify everything that’s 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.

Planning

Attendees: All team members

The 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.

Later we will discuss the commitment letter in more detail.

Sprint Review (Demo) meeting

Attendees: All team members

The Sprint Review happens on the last day of the current sprint. The project manager summarizes what’s 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.

Along with the team, the project manager assesses whether the spring was successful or not, based on the goals outlined in the sprint’s commitment letter.

After 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).

Sprint Retro meeting

Attendee: All team members

At 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.

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.

Essentially, 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.

Scheduling meetings

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.

Meeting requirements

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:

• The feature team has clear requirements and acceptance criteria for the tasks in the next sprint.
• The feature team has discussed and agreed on the details and approaches to the feature implementation.
• The feature team has created, described, and agreed on sub-tasks.
• Sub-tasks have been assigned to Feature team members.
• The team has agreed on the estimates for the tasks in the following sprint scope.

Emails and reports

Emails are a formal method of communication that is also tightly related to Scrum. Every Scrum event is followed by an email report with the results of the meeting, test, or deployment.

Here are the types of reports in a sprint.

Commitment letter

This is a letter the project manager sends to the team after each Sprint planning meeting. It lists the features the team has agreed to complete during the following sprint. It also includes a list of people involved in the process, their workloads, the amount of logged time spent on work, and the sprint’s goals.

Sprint report

This report must describe what the team accomplished, how much time it took, and whether the team reached the objective it had committed to. It is sent at the end of each sprint.

Test report

This report is created by the quality assurance team. The report must list all bugs and clarify what was fixed and what still needs to be fixed. It must also provide up-to-date information about the state of the project and any issues that were encountered, as of the moment of the report’s creation. It summarizes the evaluations of the test items, identifies the items tested, and indicates their version/revision level and the environment in which the testing activities took place. It describes the issues found during Regression testing, the affected bugs from current sprint, recommendations, etc.

Release report

This report provides updates on the development of certain features. It must include all the features listed and their status.

Chat messages

As a written method of communication, email is used to report to the client or product owner. Compared to reports and meetings, chat messaging is informal. However, there’s still a procedure applicable to it.

Chats are used for instant communication within the team. Our development team uses Slack as a corporate messenger. Having a separate messenger for work is important and convenient – important, as it remains a space for work discussions, and convenient, since you can create channels for different matters and add the people involved to the chat.

There are different communication channels, depending on the team members involved in the task. Chats provide a fast way to discuss emerging issues or the peculiarities of a task. Such channels are great for timely progress updates. Besides, the issues around a particular task are discussed in Jira (in the comments sections for a task), which allows team members to see the task’s specifications and any completed changes. This way, any issues related to a particular task are easier to track, which eliminates unnecessary communication. The combination of Jira and Confluence is ideal in this regard.

How to Develop a Communication Plan for Project Management

Now that the methods and their implications are on the table, it is possible to start putting them all together. First, there’s no standardized template for a communication plan. You can figure out what’s most convenient for you and your team, and make this the basis of your plan. Prioritize the plan’s navigation in way that works for everyone, and don’t forget to take the following steps:

Communication plan needs:

• Project size
• Number of people involved
• Competencies
• Client preferences

Communication plan methods:

• Types of meetings
• Number of meetings
• Types of reports
• Chat channels
• Assigned responsibilities

Communication plan requirements:

• Is the schedule convenient for everyone?
• Which meetings does the product owner need to participate in?
• What is the standard reporting template?
• Did you synchronize your Scrum events with all stakeholders’ schedules?

List your project’s communication needs

Every project is different, and each project’s communication needs will differ, too. You need to take into account the project’s size, number of people working on it, and its specifications. Also, it’s important to note the client’s preferences in terms of communication, as this is the only way to make the working process convenient for everyone. Based on your communication needs, you will then choose the most appropriate methods of communication.

Define the communication methods on the basis of the development process

The Scrum framework suggests the required communication events and helps organize the development process. It’s up to you to determine the stages of the process and create a sprint, choose the meetings the team will need, how much time each meeting will take, and how it will be tracked. Conveniently, you can add all these events to Google Calendar and assign roles and responsibilities to the team members. When you’ve determined and scheduled the types of meetings you will need, list the necessary data and expected results for each. For example, for grooming, you need the scope of tasks, which will be estimated, discussed, clarified and assigned as a result of the meeting.

Define communication requirements

Your communication plan will need a set of requirements. This will help you arrange all the communication sessions and, eventually, estimate the effectiveness of the process.

• Communication requirements must be based on what’s best for the project and the team (if the project is already launched). It’s important to discuss and agree on the processes and accessibility of the project information. Also, you need to know when the business owner will request reports, as they will have to report to stakeholders who have their own schedules. Thus, the schedules must align. Then you need to clarify whether you have everything you need to start or continue working.
• Discuss whether the product owner needs to participate in meetings. If so, determine which ones.
• Standardize report templates for the project, and determine their number and frequency.
• Schedule meeting dates, keeping in mind that the business already has its own agenda. For example, the product owner must report to stakeholders. These schedules must synchronize. The big picture of all the meetings is best seen in the Google Calendar. However, Scrum has rules, such as the Retro meeting must be bi-weekly and daily meetings held at the same time and location. Essentially, the framework includes the place of every meeting and report in the sprint.

Project Management Communication Plan Templates & Report Examples

Here are examples of how DjangoStars handles communication plans. (Although your project may have different needs, it’s always good to see examples.)

Commitment letter template

Sprint report template

Test report template

Conclusion

Devising a solid communication plan for your project will require some time and a few tries. Creating a perfect plan will take even more work. However, with every iteration, the communication process will become more comfortable and productive. The things you need to keep in mind are the purpose of each meeting, checkpoints, and reports. If you know the overall project goal, it will be easier to pick the right methods, as today’s technology makes everything nearly effortless.

Also, don’t be afraid to change parts of your plans if they don’t work. Eventually, you will develop a plan that is perfectly suited your particular project and will help you accomplish your particular goals.

This guide about How to Create a Project Management Communication Plan was originally posted on Django Stars blog. Written by Iryna Meshchankina - QA Lead at Django Stars