A transformation communication plan you can fill in

What this template is for

Transformation programmes fail in ways that show up in communication before they show up anywhere else: the announcement nobody understood, the milestone update that stopped arriving, the questions support could not answer. This page is a communication plan template for a transformation programme: 4 phases crossed with audiences, messages and feedback routes, on one page you fill in.

A note on the statistics first, because this field is full of them. Failure rates of 70%, success rates of 30%, digital-first adoption at 89% circulate constantly, none carries a primary you can check, and the numbers contradict each other freely. What is checkable is the mechanism underneath all of them: people cannot support a change they do not understand, and cannot flag a problem they have no route to report. The template exists to make both possible.

The 4 phases

Communication work in a transformation has 4 phases, and each has a different job:

Phase	The job	What can still change
Before	Context: why the organisation is changing, what is not changing, who decided	Scope and sequencing. Input is consultation in the honest sense
Launch	The decision itself: what was decided, the timeline, what it means for each audience	Nothing in the decision. Feedback routes to delivery choices
Delivery	The long middle: milestones, slippage, course corrections	Rollout order, training shape, support load
Landing	What changed, what was learned, what is next	The next programme. This is where lessons either get captured or evaporate

The honesty rule from the stakeholder engagement framework applies phase by phase: run Consult in Before and mean it, run Inform at Launch and do not pretend otherwise. Consultation scheduled after the deciding is the classic transformation failure.

The audiences

Start from your internal audience map and add the external rows a transformation creates. In most programmes the rows that matter are:

• The people whose daily work changes: their tools, process or reporting lines
• The people whose data or hand-offs change without their work visibly changing
• Leadership, who must resend the message when it stalls
• Support and customer-facing staff, who answer everyone else's questions
• Customers who touch changed journeys
• Suppliers and partners whose integrations move

The template, worked through an example

The example is a CRM replacement affecting a 60-person sales and support organisation. Copy the structure and change the rows.

Phase	Audience	The message	Channel and timing	Feedback route
Before	Sales and support teams	The current CRM is being replaced; here is the shortlist criterion that involves you	Team meetings, 3 weeks before selection closes	The delivery lead, logged
Before	Customers	Nothing yet	Silence is correct here	n/a
Launch	All staff	The decision, the date, what changes for whom, what does not change	All-hands, then the written record the same day	Named programme inbox
Launch	Customers using integrations	The integration endpoints change on the go-live date; here is the documentation	Email from account owners, 8 weeks ahead	Account owners
Delivery	Affected teams	Progress against milestones; every slip announced with what is known, what is not, and the next update	Fortnightly written update, monthly live session	Programme inbox, triaged weekly
Delivery	Support	What customers will ask about this month, and the current answers	Weekly briefing note	Support lead
Landing	All staff	What changed, what slipped and why, the 3 things learned	All-hands, 1 month after go-live	Retrospective, published
Landing	Customers	The change is complete; here is what to expect next	Release note	Support, as normal

Two rows deserve attention. The customer silence row exists because templates push teams to communicate everything to everyone, and the Before phase is when external audiences usually need nothing. The support rows exist because support absorbs every gap in everyone else's communication, and giving them a weekly brief and a feedback route is cheaper than discovering the gaps from escalations.

The feedback route is the plan's spine

The component most communication plans omit is where replies go and which decisions they can affect; the engagement versus communication plan comparison covers the general argument. In a transformation it matters more, because the route has to change phase by phase. Input in Before can change the scope. Input in Delivery changes the rollout. Input after Landing belongs to the retrospective. People deserve to be told which of the 3 they are giving.

When the plan meets slippage

Transformations slip, and the slip is where trust is decided. Every slip announcement needs the holding structure: what is known, what is not yet known, and when the next update comes. That structure, and the compressed timing around it, is covered in crisis communication: what changes, and what you can prepare.

Resistance that arrives mid-programme is usually one of 4 modes, and the response depends on the diagnosis. Difficult stakeholders, and what each one needs has the decision tree.

One pattern is worth separating from the other 3, because no communication plan can fix it. Where leaders give different answers to the same question, teams follow the answer they prefer and the programme develops 2 versions of itself. That reads as resistance and is not: it is people acting reasonably on inconsistent instructions. Culture change in a digital transformation, and where it stalls covers the conditions that produce it.

Measuring the plan

Keep it small and phase-scoped: coverage, meaning did each row receive its message; comprehension, meaning can someone in the group say what changed and what they do next; and feedback acted on, meaning how many replies changed anything. These are the internal numbers from the minimum viable measurement plan, applied per phase.

Fill the Launch row first

Copy the template and fill the Launch row first: the announcement you can already write. Then work backwards to Before, which is the phase that always runs out of time, and forwards to Delivery. If the Before row cannot honestly say what input can still change, you have found the plan's first problem, and you found it before the programme did.