Because sending updates isn’t the same as creating clarity.
Every ERP program has a communications plan.
A document. A timeline. A list of deliverables: announcements, newsletters, training communications, leader toolkits, go-live countdown emails. On paper, it looks complete. Every box is checked. Every milestone has a corresponding communication.
And yet, in many ERP programs, the same problems show up regardless of how thorough the plan is.
People feel confused despite frequent updates. Managers hesitate to cascade messages because they don’t feel confident enough in their own understanding to explain them. Questions repeat across teams — the same questions, weeks apart, about things that were ostensibly communicated months ago. Adoption lags behind the timeline the plan assumed.
Which raises a harder question: if the plan exists and has been executed, why isn’t it working?
Because most ERP communications plans are designed around activity, not clarity. They answer “what will we send?” rather than “how will we ensure people understand?” And those are fundamentally different questions — with fundamentally different answers.
The difference between a plan and a clarity system
A traditional ERP communications plan answers three questions: what will we send, when will we send it, and through which channels? The deliverables are defined. The timeline is mapped. The channels are assigned. The communication workstream can point to a calendar that has been executed on schedule.
A communications plan that works answers something different: how will we ensure that people across this organization understand what this change means for them — consistently, over the full duration of the program?
That shift changes the design of the plan entirely. Because ERP communication isn’t a campaign with a launch date and a conclusion. It’s a long-duration clarity system — one that has to maintain shared understanding across a program that runs twelve to twenty-four months, through multiple phases, across multiple functions, with multiple leadership voices all communicating simultaneously.
When the plan is designed as a campaign, it optimizes for output. When it’s designed as a clarity system, it optimizes for understanding. And understanding — not output — is what produces adoption.
Where most ERP communications plans break down
The failures are almost always in design, not in effort. Most ERP communications teams work hard. The plan breaks down because it was built around the wrong objective.
1. Optimizing for volume rather than understanding
The instinct when communication isn’t working is to add more of it. More emails, more updates, more channels, more frequency. The assumption beneath that instinct is that the problem is insufficient information — that if people just received more, they would understand more.
But in ERP environments, where the transformation is complex, the timeline is long, and people are already managing significant operational load, more communication without more structure produces signal fatigue rather than clarity. Messages blur together. People stop reading updates from channels that have never given them the specific information they needed. Important signals get lost inside general updates. And the communication team works harder while understanding stays flat or declines.
Clarity is not created by volume. It’s created by relevance — communication that specifically answers the questions people are actually asking — and by structure — communication that places each piece of information in a sequence that makes the whole picture coherent. (For the full treatment of volume vs clarity, read Change Communications: Why Clarity Matters More Than Volume.)
2. Leading with system detail instead of meaning
Most ERP communications plans lead with the system — features, functionality, deployment timelines, cutover dates. This content is easy to produce because it comes directly from the project plan. It’s accurate. It’s timely. And it answers the wrong question.
People aren’t trying to understand the system in the abstract. They’re trying to understand what the system means for their work specifically. What changes in the process they do every day. What happens to the decision they currently own. What the new system enables them to do that the old one didn’t.
When plans lead with system detail before establishing why the change is happening and what it means at the role level, they build awareness without orientation. People know the system exists and when it goes live. They don’t know how to work inside it differently — and that’s the knowledge that produces behavior change.
3. Treating communication as one-way
Most ERP communications plans are designed for distribution. Messages go out. Understanding is assumed. The plan moves on to the next deliverable.
But ERP environments are too complex for passive communication. When people receive information about a change that touches their core workflows, their first response is almost never “I understand.” It’s “I have questions.” “I’m not sure what this means for the process I own.” “The message said one thing but my manager said something slightly different.”
If the plan doesn’t create structured space for questions, interpretation, and feedback — through manager cascades, through feedback mechanisms, through channels where people can surface confusion — that confusion accumulates silently. It shows up at go-live as the questions that should have been answered six months earlier. (For why this matters, read Why ERP Projects Fail.)
4. Under-equipping managers
Managers are the primary translators of change in any organization. They’re the people employees actually talk to. They’re the ones who take an organizational narrative and make it personally relevant for a team of twelve people with specific questions about their specific jobs.
But most ERP communications plans give managers dense slide decks with talking points written for executives, last-minute updates that arrive the night before a team briefing, and no real guidance on how to handle the questions their teams are most likely to ask. Then the plan assumes that manager cascades will work.
Managers don’t need more content. They need context — the why behind the message, not just the what. They need language they can use in conversation rather than paragraphs they read aloud. And they need time — enough advance notice to prepare, to develop their own understanding, and to anticipate the questions their teams will ask before they’re standing in front of them.
Six moves that make an ERP communications plan actually work
These aren’t additions to a standard communications plan. They’re a different design philosophy — one that optimizes for understanding rather than output.
Move 1 — Start with a narrative spine before planning any content
The first thing a working ERP communications plan defines is not a timeline or a channel matrix. It’s the core story.
Where is the organization today, and what’s not working about it? What is the ERP program changing, and why is this the right response to that problem? What does this mean for the people in this organization? Where is the organization going, and what does success look like?
That narrative spine becomes the foundation for every piece of communication that follows. Announcements, training materials, manager talk tracks, go-live communications — all of them should be expressions of the same core story, not independent pieces of content. When the narrative spine is missing, different communications tell different stories. Narrative drift builds. And once narrative drift takes hold across a twelve-to-twenty-four month program, the work of rebuilding coherence is significantly larger than the work of designing it correctly from the beginning.
If the narrative spine isn’t clear — if the leadership team can’t tell the same story in their own words without contradicting each other — the plan should not proceed to content development. (For how to build and align on a narrative spine, read The Role of Storytelling in ERP Transformations.)
Move 2 — Sequence communication for how people actually process change
People don’t absorb ERP transformations comprehensively. They process them in layers — starting with the most personally relevant and building outward from there as clarity at each layer enables them to absorb the next.
The sequence matters: why is this happening comes before what is changing, which comes before what this means for me specifically, which comes before how I operate in the new state. When plans lead with operational detail before establishing meaning, the detail has nowhere to land. People receive it without being able to connect it to anything they already understand about why the change is necessary.
Design the communication calendar around this sequence rather than around project milestones. The project milestone is when something is technically ready to be communicated. The communication moment is when people are ready to receive it — and those two things are rarely the same. (For the psychology behind this sequencing, read Why Employees Don’t Resist Change — They Resist Uncertainty.)
Move 3 — Build role-level translation explicitly into the plan
Enterprise-level messaging creates awareness. Role-level messaging creates action. A working ERP communications plan doesn’t just produce enterprise-level content and assume it will translate — it explicitly develops role-specific communication for the audiences most significantly impacted.
For each major audience group, the plan should answer: what changes in their specific workflow, what decisions shift in terms of who makes them and how, what tools replace what, and what stays in their control. The Messaging Matrix is the tool for this — one narrative spine, multiple audience-specific translations, zero distortion of the core story.
If a field technician and a finance manager are both impacted by the same ERP implementation, they need the same story with completely different entry points. A plan that only produces one version of the story will produce adoption in the audience that story was written for and confusion in everyone else.
Move 4 — Create a communication rhythm, not just milestone communications
Most ERP communications plans are driven by project milestones. System design complete — send an update. Training launches — send an announcement. Go-live approaching — send a countdown. These milestone communications are necessary. They’re not sufficient.
People experience the change continuously, not just at milestones. Between the project milestones are weeks and months where the official communication goes quiet and the informal networks fill the silence. The Cadence Map for an ERP program should define a regular rhythm of leadership communication that runs between milestones — not just at them.
A predictable cadence — weekly or biweekly leadership updates, consistent manager briefings, regular channels for questions and answers — reduces the anxiety that silence creates and signals that someone is paying attention even when there’s no milestone to announce. Predictable rhythm is one of the fastest ways to build the trust that makes people willing to wait for clarity rather than filling the gap themselves.
Move 5 — Equip managers before you cascade through them
Manager communication should be treated as a separate workstream in the plan, not as a downstream of the all-staff communication. Managers need advance information — enough lead time to develop their own understanding before they’re expected to communicate with their teams. They need context — not just the what of the message but the why, so they can answer questions that the script didn’t anticipate. And they need simple, conversational language — talk tracks that work in a team meeting, not slide decks that require a projector.
The Anchor Framework™ provides the structure for manager alignment sessions — define the purpose of the cascade, anchor on what’s genuinely true, decide on the direction before anyone talks to their teams. When managers feel genuinely prepared, they communicate with the confidence and consistency that builds trust at the team level. When they feel under-equipped, they hedge, they improvise, and the narrative fragments in exactly the way that produces the “same program, different stories” pattern that ERP programs are most vulnerable to.
Move 6 — Treat communication as a feedback system, not an output system
This is the most underused move in ERP communications planning — and the one that most directly determines whether the plan actually produces understanding or just produces content.
A feedback-oriented communication plan doesn’t just send messages and move on. It creates mechanisms for seeing what landed and what didn’t. What questions are people asking repeatedly — and what does the pattern of those questions reveal about where the narrative is unclear? Are managers able to cascade confidently, or are they calling back for clarification on the same points? Are the same confusions surfacing across multiple teams, which suggests a systemic gap in the communication rather than individual misunderstanding?
This information — gathered through manager feedback channels, through help desk patterns, through structured listening sessions, through simple pulse questions — is what allows the plan to adjust. Communication in a complex, long-duration program is not a fixed document. It’s a living system that needs to respond to what it learns about where understanding is and isn’t building.
Organizations that treat communication as output measure open rates and attendance. Organizations that treat it as a feedback system measure whether people can explain the change in their own words — and use the gaps in those explanations to identify exactly where the next communication needs to go.
The real measure of a working ERP communications plan
Not how much was sent. Not how many sessions were held. Not how many materials were produced and distributed.
The real measure is behavioral: can people across the organization explain what’s changing in their own words, including what it means for their specific role? Are leaders at every level reinforcing the same core story without contradicting each other? Are decisions happening at the right level without constant escalation for clarification? Are the questions people are asking getting simpler and more operational over time — or are they getting louder and more confused?
If the answer to those questions is yes, the plan is working. If it’s no, the plan needs to be redesigned — not expanded. Adding more communication to a plan that isn’t producing understanding is the most common mistake ERP programs make. The fix is almost never more content. It’s clearer architecture.
What this looks like in practice
I worked with a communications team six months into a large-scale SAP implementation. The plan had been executed faithfully — every milestone communication had gone out on time, the newsletter cadence was consistent, and the training announcements had produced high completion rates.
And yet adoption was stalling. The same questions kept surfacing in manager inboxes. Different functions were describing the program in different terms. And the help desk was fielding calls that pointed not to system issues but to understanding gaps — people who didn’t know what the system was supposed to replace, why their specific process had been redesigned, or who owned a decision that had previously been theirs.
The plan had produced activity. It hadn’t produced a clarity system.
We rebuilt around the six moves. First, aligned on the narrative spine — which required a leadership session that revealed three different versions of the “why” story that had never been reconciled. Second, developed role-specific communication for the three most impacted audience groups, which had never been produced separately from the enterprise-level content. Third, established a biweekly manager briefing cadence with talk tracks written for conversation rather than presentation. Fourth, created a feedback loop through a monthly pulse question sent to managers asking what their teams were most confused about.
Within eight weeks, the pattern of questions had shifted. The repeating questions stopped repeating — because the gaps they were pointing to had been identified and addressed. Manager confidence in cascading improved measurably. And the escalations that had been consuming program leadership time dropped significantly.
The plan hadn’t gotten bigger. It had gotten clearer.
Final thought
ERP communications plans don’t fail because they’re missing pieces.
They fail because they’re built around the wrong objective — activity instead of clarity, output instead of understanding, milestones instead of meaning.
A plan that works doesn’t try to communicate more. It makes the change understandable.
And when that happens — when people can explain the change in their own words, when leaders reinforce the same story, when managers cascade with confidence — people don’t just hear the message.
They act on it.
FAQs: ERP communications plan
Six essential elements: a narrative spine that defines the core story before any content is developed, communication sequenced for how people actually process change rather than for project milestones, role-level translation for the most significantly impacted audience groups, a predictable communication rhythm that runs between milestones not just at them, manager enablement treated as a separate workstream rather than a downstream of all-staff communication, and a feedback mechanism that tests whether understanding is building rather than just whether content is being distributed.
Because they’re designed around activity rather than clarity. They answer “what will we send and when?” rather than “how will we ensure people understand what this change means for them?” The result is a plan that produces high output and low comprehension — frequent communication that doesn’t reduce confusion because it was designed to distribute information rather than create understanding.
Through the full adoption curve — which extends three to six months beyond go-live, not just up to it. Most plans front-load communication in the pre-go-live period and go quiet at exactly the moment people are actually working inside the new system for the first time. The post-go-live reinforcement period is where adoption is either sustained or lost.
Not by counting outputs — emails sent, sessions held, materials produced — but by measuring behavioral indicators. Can people explain the change in their own words? Are leaders reinforcing the same story without contradicting each other? Are decisions happening at the right level without constant escalation? Are the questions people are asking getting simpler and more operational over time? If yes, the plan is working. If no, the architecture needs to be redesigned rather than expanded.
The narrative spine is the core story that every piece of ERP communication expresses: where the organization is today and what’s not working, what the ERP program is changing and why, what it means for the people in the organization, and where things are going. It’s the foundation that all communications are built on — not a tagline or a key message, but a fully developed story that answers the questions employees are actually asking before the official communication can answer them.
Give them advance information — enough lead time to develop their own understanding before they’re expected to communicate with their teams. Give them context — the why behind the message, not just the what, so they can handle questions that weren’t anticipated. Give them conversational language — talk tracks that work in a team meeting rather than slide decks that require presentation. And give them a feedback channel so they can surface what their teams are confused about before the confusion compounds.
The five principles of The Clarity Framework™ map directly onto the six moves in this article. Diagnose corresponds to the feedback system — identifying where understanding is breaking down before adding more content. Define is the narrative spine — the single story that all communication then expresses. Design is the communication rhythm and sequencing — delivering information in the order people can absorb it. Deliver is the manager enablement and role-level translation — communicating with empathy and specificity at the audience level. And Measure is the real measure of the plan — testing whether people can explain the change rather than counting whether content was distributed.
Ana Magana is a change management and communications strategist based in Calgary, Alberta. She helps organizations design ERP communications plans that produce understanding, not just awareness — through The Clarity Framework™.
Building an ERP communications plan and not sure it’s working? Work with Ana →
Related reading: Why ERP Projects Fail — And How Communication Determines the Outcome → The Role of Storytelling in ERP Transformations → How to Communicate During a Major System Transition →