Why We Have Communication Management Plans
Projects can be time-consuming and costly, and tie-up valuable employees for long periods with no guarantee of the outcome initially hoped for. So, the responsible thing to do is to agree upfront on how everyone will be kept informed of the project’s progress, risks, issues, etc. This is where a good communications management plan comes in.

The project communications management plan outlines how all the various stakeholder groups will be kept informed of progress and issues. It outlines the frequency, format and distribution channels that will be used for communications. Given the high rates of change often experienced on agile projects, we might expect more emphasis on communications to keep everyone on the same page.

Show, Don’t Tell
Despite the lack of a formal communications management plan, agile approaches emphasize communication and information sharing extensively. In fact, transparency and sharing of information are baked into many of the agile practices. Let’s examine a few…

• Demos – Having the team demonstrate increments of functionality at the end of every iteration shows what the project has achieved to date. The demonstrations are often accompanied by project spend summaries and updates on expected completion dates. Together they provide a good snapshot of progress and an opportunity for business representatives to provide feedback.

Frequent demos mean the project never disappears for long. Instead, the team regularly surfaces from work to show where they are with progress and discuss what should come next. It is this predictable cadence of show-and-tell sessions that creates the dolphins-versus-submarines comparison. 

Agile projects frequently surface to show progress and discuss issues. They are like dolphins, frequently surfacing never too far from where they last submerged.

Predictive projects may have less to show the business and so have an increased reliance on communication management plans to keep everyone informed. After kickoff, a predictive project might be busy in analysis and design for long periods with only internal deliverables to show for their work. In these circumstances, they behave more like submarines, disappearing from view for long periods then emerging to present the solution. 

• Kanban boards - The concept of “make work visible” is applied on agile projects to show what tasks are being worked on currently and the status of pending and completed items. Since knowledge work is often novel or unprecedented in the organization, it helps to have visual cues for it so people can point to it or examine its position on a Kanban board to determine its status in the development process.

Modern agile project management tools have a variety of Kanban board and backlog viewing tools so stakeholders can review progress and task status remotely. Since these tools also track when work changes state, they can also calculate and display metrics such as lead time, cycle time, WIP and throughput rates that help determine likely completion dates and costs.

• Information radiators – A common theme between the various lean and agile approaches is to show and share information. XP has the practice “informative workspace,” Scrum encourages “transparency,” and Kanban development talks about making “process policies visible.” They promote graphing and sharing information—both good and bad—via large charts and graphs known as information radiators.

Information radiators can show any data the team wants to display. This could be a list of impediments or, as shown in the graph below, the cumulative threat scores for five well site-related risks over time:

These displays are used by the teams but also shared broadly with other stakeholders. Development team members, rather than a project manager, generally create these information radiators and, in doing so, broaden the set of stakeholders reporting on the project.

• Daily stand-ups – Daily stand-ups are short (15 minute) meetings where team members share their progress, plans and raise any issues or impediments they have. It is an inter-team communication session rather than a reporting up of status to a scrum master or project manager. It facilitates collaboration, load-sharing and team planning. Other stakeholders may occasionally drop in to observe, but the goal is to help team members communicate among themselves.

• Retrospectives – At the end of each iteration (typically every week or two), the team members meet to review how things are working and if any improvements can be made. This meeting is another scheduled event focused on information sharing.

The Agile Alternative to Communications Management Plans
By having multiple communication-focused events as part of the core agile practices, it removes some of the need for creating a separate communications management plan. Instead, people working in or with agile teams know there are events like demos, stand-ups and retros they can attend to learn about project performance. Likewise, there will also be Kanban boards and other information radiators available online to get project metrics.

Hybrid Realities
The dolphins-and-submarines analogy is a cute starting point to help explain some of the differences between predictive and agile communication styles. However, real-life projects are usually more complicated. Predictive projects that incorporate a proof-of-concept phase resurface and show progress. Phase-gate reviews may not demonstrate increments of a solution, but they are planned review points to assess progress, issues and funding.

Likewise, not everybody can attend a demo—nor wants to watch a recording of one to get a single question answered. The data on agile information radiators may not make it to all interested stakeholders, and pull systems for providing project data from websites will only work if people request (pull) the data. 

Mix and Match
It is normal and often necessary to schedule additional demos or review points within predictive projects. It may also be required to create communication plans for agile projects, especially those with distributed stakeholders. We should not assume that just because the information is available that it is being consumed or understood.

So, while agile projects frequently surface to show their progress and predictive projects can seem to disappear from our radars (sonars?) if we do not keep close tabs on them, we need to do more. We need to ask people how they want to hear about the project and ensure they know where to find the information. Check-in with them to make sure they were able to access and interpret it correctly.

We can use retrospectives and surveys in any project to learn about communication needs and wants. Given that the cost-of-change curve ramps up quickly, it is better to know about good news and bad news (in particular) as soon as possible. So, keep communicating and keep asking for feedback.

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]