# Communication Management Plan: [Project name]

> Plan for who receives which project information, why, through which
> channel, how often and from whom, including meeting cadence, escalation
> path, document repository and feedback. Based on common project
> management practice. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Build the plan from the stakeholder register: every high-influence or
  high-interest stakeholder must appear in the communication matrix.
- Plan for purpose, not volume. Each item should answer "what does the audience need
  to decide or do with this?"
- Name an owner for every communication; "the team" is not an owner.
- Review the plan at each stage gate and after any feedback that shows a message was
  missed or misunderstood.
-->

| Field | Value |
|---|---|
| Document ID | [CP-PROJECT-001] |
| Project | [Project name] |
| Version | [0.1] |
| Owner | [@project-manager] |
| Approved by | [@sponsor] |
| Related | [Stakeholder register SR-001, Project management plan PMP-001] |
| Last updated | YYYY-MM-DD |

## 1. Objectives

<!-- Guidance: State what good communication must achieve for this project. Make the objectives checkable. -->

Communication on [Project name] aims to:

- keep decision makers informed early enough to decide before deadlines;
- give affected staff accurate, timely information about what changes for them and when;
- surface risks and issues quickly through a known escalation path;
- keep one source of truth for project documents and decisions.

## 2. Principles

<!-- Guidance: A short list of rules that apply to all communication. -->

All project communication follows these principles.

| Principle | What it means in practice |
|---|---|
| One source of truth | Decisions and documents live in the repository; email links to them |
| Plain language | Lead with the outcome and the ask; avoid internal jargon and acronyms |
| No surprises | Bad news is shared as soon as known, with a proposed response |
| Accessible | Documents meet [accessibility standard]; recordings have captions |
| Confidentiality | Commercial and personal data shared only with authorised audiences |

## 3. Communication matrix

<!-- Guidance: One row per communication item. Purpose explains the action expected from the audience. Common mistake: a matrix with many reports and no stated purpose. -->

The matrix lists every planned communication.

| ID | Audience | Information | Purpose | Channel | Frequency | Owner | Format |
|---|---|---|---|---|---|---|---|
| COM-01 | *Example:* Sponsor | Status, risks, decisions needed | Decide on escalations within tolerance | Email plus 30-min call | Biweekly | Project manager | Status report template |
| COM-02 | *Example:* Steering committee | Progress vs baseline, financials, change requests | Approve stage gates and changes | Meeting | Monthly and at gates | Sponsor | Steering committee report |
| COM-03 | *Example:* Project team | Priorities, blockers | Coordinate daily work | Stand-up (video) | Daily | Workstream leads | Board review |
| COM-04 | *Example:* Branch staff | What changes, when, training dates | Prepare for the new process | Intranet article, team briefing | Monthly; weekly during rollout | Change lead | Article, slide pack |
| COM-05 | *Example:* Compliance officer | KYC design, test evidence | Review and sign off | Formal review meeting | At design and test milestones | Business analyst | Review pack |
| COM-06 | *Example:* Vendor | Plan changes, defects, acceptance | Align delivery | Joint progress meeting | Weekly | Project manager | Minutes and action log |
| [ID] | [Audience] | [Information] | [Purpose] | [Channel] | [Frequency] | [@owner] | [Format] |

## 4. Meeting cadence

<!-- Guidance: List standing meetings with their decision rights, inputs and outputs. Cancel meetings that have no decision or coordination purpose. -->

Standing meetings are scheduled as follows.

| Meeting | Chair | Attendees | Frequency and length | Inputs | Outputs |
|---|---|---|---|---|---|
| Steering committee | Sponsor | Committee members, PM | Monthly, 60 min | Steering report sent 3 working days before | Decisions, actions, minutes within 2 days |
| Project board review | Project manager | Workstream leads | Weekly, 45 min | RAID log, schedule update | Updated RAID log, action list |
| Daily stand-up | Workstream lead | Workstream team | Daily, 15 min | Task board | Blockers raised |
| Vendor progress | Project manager | Vendor lead, tech lead | Weekly, 30 min | Vendor report | Action log |
| [Meeting] | [@chair] | [Attendees] | [Frequency] | [Inputs] | [Outputs] |

## 5. Escalation path

<!-- Guidance: Define levels, time limits and who to contact. Make escalation routine, not personal. -->

Issues and decisions that cannot be resolved at one level move to the next within the time limits below.

| Level | Escalate to | When | Response expected within |
|---|---|---|---|
| 1 | Workstream lead | Blocker affecting a task | 1 working day |
| 2 | Project manager | Blocker affecting a milestone or another workstream | 2 working days |
| 3 | Sponsor | Forecast exceeds PM tolerance (schedule, cost, scope) | 5 working days |
| 4 | Steering committee | Forecast exceeds sponsor tolerance or benefits at risk | Next meeting or extraordinary session |

The escalation flow is shown below.

```mermaid
flowchart LR
  T["Team member"] --> WL["Workstream lead"]
  WL -->|"not resolved in 1 day"| PM["Project manager"]
  PM -->|"beyond PM tolerance"| SP["Sponsor"]
  SP -->|"beyond sponsor tolerance"| SC["Steering committee"]
```

## 6. Document repository

<!-- Guidance: Say where things live and how they are named, so nobody searches email threads for the latest version. -->

All project documents are stored in [repository name and link]. Naming follows `[ProjectCode]-[DocType]-[Number]-v[major.minor]`, for example `DOB-PMP-001-v1.2`.

| Folder | Contents | Access |
|---|---|---|
| 01 Governance | Charter, plans, steering packs, minutes | Project team, steering committee |
| 02 Requirements and design | Requirements, designs, decisions | Project team |
| 03 Delivery | Test evidence, release notes | Project team, vendor |
| 04 Change and training | Communications, training materials | Project team, change network |
| 05 Commercial | Contracts, invoices | PM, procurement, finance only |

## 7. Communication methods and tools

<!-- Guidance: List approved tools and what each is used for. -->

The project uses these tools for the stated purposes only.

| Tool | Use | Not for |
|---|---|---|
| [Email] | Formal notices, approvals | Ongoing discussion |
| [Chat channel] | Quick coordination within the team | Decisions (record them in the decision log) |
| [Video meeting tool] | Meetings, recorded training | Confidential commercial discussions with recording on |
| [Intranet page] | Updates for affected staff | Draft or unapproved content |

## 8. Feedback and effectiveness

<!-- Guidance: Plan how you will learn whether communication works and act on it. -->

Effectiveness is checked through [a short pulse survey of affected staff each month, attendance and open rates, and questions raised at briefings]. Results are reviewed at the project board meeting and the plan is adjusted.

| Measure | Target | Source |
|---|---|---|
| Staff who know the go-live date and their training slot | At least 90% | Pulse survey |
| Steering pack sent at least 3 working days before meeting | 100% | Meeting log |
| Questions answered within 5 working days | At least 95% | Feedback mailbox |

## 9. Plan maintenance

<!-- Guidance: Record changes to the plan itself. -->

The plan is reviewed at each stage gate. Changes are recorded below.

| Version | Date | Change | Author |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | Approved | [@name] |
| 1.1 | YYYY-MM-DD | *Example:* Added weekly branch briefings for rollout | [@name] |

## Standard and licence note

Based on common project management practice for communication planning.
This template is original text written for this collection. Template
licence: MIT.