Create a successful NetSuite adoption communication plan with best practices to engage employees and stakeholders, drive buy-in, and ensure project success.
Communication is the part of a systems project that everybody agrees matters and almost nobody plans. It happens, in the sense that emails get sent and meetings occur, and it happens reactively rather than to a design.
The consequence is predictable. People hear about the project inconsistently, form their own view of what it means for them, and arrive at go live either unprepared or resistant. Neither is a training problem and both get treated as one.
This article covers how to plan the communication properly, which is a smaller exercise than it sounds and returns more than most other adoption activity.
Being clear about the purpose prevents the plan becoming a schedule of announcements.
The first purpose is preventing the vacuum. In the absence of information people construct their own account, and the account they construct is generally worse than the truth. Redundancies, surveillance, a decision made by people who do not understand the work.
The second is preparing people for a specific change. Not that a project is happening, but that their Tuesday will look different in a particular way.
The third is surfacing objections early enough to address them, since an objection raised in month two is information and the same objection raised at go live is resistance.
And the fourth is maintaining credibility, which means the project being trusted when it says something, and which is spent rather than accumulated.
The most common failure is treating everybody as one audience, which produces messages that are relevant to nobody.
Executives need to know whether the project is on track, what decisions are required, and what risks are live. They do not need feature detail.
Managers need to know what changes for their team, when, what they will be asked to contribute, and what to tell their people. They are the channel through which most communication actually reaches the organisation.
End users need to know what changes for them specifically, when it happens, what support exists and how they will be trained. Everything else is noise to them.
Process owners and testers need considerably more detail, since they are participants rather than recipients.
And customers and suppliers need to know anything that changes how they interact with you, which is frequently forgotten until an invoice looks different and somebody calls.
The timing principle that matters most is that the first communication should arrive before the rumour does.
Systems projects are not secret. People notice the meetings, the consultants and the questions about how their process works. Where nobody has told them what is happening, they conclude something.
The initial message needs very little. That a change is coming, why in terms that matter to them, roughly when, and that more detail will follow.
That last element is important, because a single announcement followed by silence produces more anxiety than no announcement at all. Committing to a rhythm is part of the first message.
Where a project has already started without this, the correct response is to do it late rather than to conclude the moment has passed.
The reason given for a systems project is usually the reason that persuaded the board, and it is rarely the reason that means anything to the people affected.
Improved data visibility, better reporting and operational efficiency are phrases from a business case. They describe benefits that accrue to the organisation rather than to the person reading.
What works is specific and personal. You will stop rekeying orders from email into two systems. You will be able to see stock at the other warehouse without ringing them. You will stop chasing approvals by email.
That requires knowing what people currently find frustrating, which requires asking, which is a reason to involve people in discovery beyond the direct benefit to the design.
Where a particular group genuinely gains nothing, saying so is better than inventing a benefit. People know when they are being sold to.
The single most credibility preserving thing a project can do, and the one most often avoided.
Every system change makes something harder for somebody. More fields to complete, an approval that did not exist, a process with more steps because it now captures something the business needs.
Projects that only communicate benefits lose credibility the moment somebody encounters the cost, and after that everything else the project says is discounted.
Projects that name the cost upfront, explain why it is worth it, and acknowledge who bears it, are believed when they describe the benefits.
The formulation that works is straightforward. This will take you two extra fields per order. The reason is that finance currently cannot tell which customers are profitable, and those fields are what makes that possible.
People accept costs they understand considerably better than costs that were not mentioned.
The channel matters as much as the message and it varies enormously between organisations.
Email works for people who read email, which excludes a substantial part of the workforce in operational businesses.
Team meetings work where managers actually run them and where the manager has been briefed properly, which is a dependency worth checking.
Physical notices work in warehouses and production areas better than anything digital.
Intranet pages work as a reference and poorly as a way of telling somebody something, since it requires them to go and look.
The practical approach is to use more than one for anything important, and to check whether the message landed rather than assuming it did.
Most communication reaches the organisation through line managers, which means the project's real audience for detailed communication is a small group.
That is efficient and it depends on managers being briefed properly rather than receiving the same message as everybody else.
What managers need is what changes for their team, when, what they will be asked to release people for, what questions they are likely to be asked, and honest answers to those questions including the uncomfortable ones.
Where a manager is asked a question they cannot answer, the project's credibility suffers rather than the manager's. Anticipating the questions and arming them is what prevents that.
A short manager briefing before each significant communication, so they hear it first and can prepare, is one of the highest return practices available.
Regular short communication beats occasional detailed communication comfortably.
A brief update on a predictable cadence establishes that information will arrive, which removes the need for people to seek it or speculate.
Monthly is generally right for the wider business during the middle of a project, moving to weekly as go live approaches and daily during the first week after.
The content can be short. What happened, what is next, what we need from you. Three lines is adequate and considerably better than nothing.
The discipline is that it arrives even when there is nothing exciting to report, because a missed update is read as a problem.
Projects that only communicate good news are believed until the first visible difficulty, and then they are not believed at all.
Something will go wrong. A date will move, a decision will prove harder than expected, a test will reveal something significant.
Reporting that early, with what is being done about it, builds credibility that is available when it matters. Reporting it late, or letting people discover it, spends credibility that cannot be recovered quickly.
The formulation matters. State what happened, what it means, what is being done, and what the revised position is. Avoid minimising, since people who were told something was minor and found it was not will discount the next assessment.
Dates are the most scrutinised part of any project communication and the most damaging when handled badly.
Where a date is genuinely uncertain, saying so is better than stating a date that moves. A range with the reason for the uncertainty is credible. A confident date that slips twice is not.
Where a date changes, communicate it promptly with the reason rather than letting people notice.
And distinguish clearly between the go live date, which affects everybody, and internal project milestones, which mostly do not. Communicating milestone slippage to the whole business creates anxiety about something that may not affect the outcome.
Communication intensity should rise sharply as go live approaches, and the content becomes practical rather than contextual.
Specific dates and what happens on each. When the old system stops, when the new one starts, what to do in between.
What to do differently on day one, in concrete terms for each role.
Where to get help, who specifically, and how quickly to expect a response.
What will be slower at first, and for how long, because setting that expectation prevents the productivity dip being read as failure.
And what to do if something goes wrong, since people who know the escalation path use it rather than inventing a workaround.
Communication during this period is different in character, because the audience is now experiencing the change rather than anticipating it.
Daily updates work here, covering what is known to be a problem and what is being done, which prevents everybody reporting the same issue.
Acknowledging difficulty is important. A project that insists everything is going well while people are struggling loses the room entirely.
Publicising fixes matters more than it seems. When something raised on Monday is fixed by Wednesday and people are told, it demonstrates that raising things produces a result, which determines whether they keep raising things.
And the opposite lesson is learned just as fast. Issues raised into silence teach people to stop raising them and start working around instead.
Communication that only goes outward is broadcasting, and it misses the information the project most needs.
Build in mechanisms for things to come back. Questions collected and answered visibly, so the same question is not answered privately fifteen times. Concerns raised through managers and actually reported upward. Somebody walking around during the first weeks rather than waiting for tickets.
The most useful information rarely arrives through formal channels, because people do not raise things they have found a workaround for.
Asking specifically is what surfaces it. Not whether everything is working, which gets a polite yes, but showing me how you processed that order this morning.
The audience most often forgotten and the one where the consequence is most visible externally.
Where invoices will look different, tell customers before the first one arrives.
Where a portal or a payment reference changes, tell them with enough notice to update their own systems.
Where there may be a period of slower response, say so rather than letting them experience it unexplained.
And tell your own customer facing people first, so they are not learning about the change from a customer asking about it.
The whole thing can fit on a page, and a page that exists beats a comprehensive plan that does not.
List the audiences. For each, note what they need to know, when, through which channel, and who sends it.
Set the rhythm for the wider business and commit to it.
Identify the manager briefing points before each significant communication.
Plan the intensification in the final weeks and the first fortnight.
And name who owns it, because communication with no owner reverts to happening reactively.
Communication is the cheapest adoption intervention available and the one most often left to happen by itself.
The useful first step is asking a few people outside the project what they think is happening and what it means for them. The gap between their answer and reality is the size of the problem you currently have.
Our piece on NetSuite user adoption covers the wider adoption programme this sits within, and training strategies covers the delivery that follows.
Our approach to NetSuite implementation covers where communication sits in the project structure.
If adoption is your concern and you would like a view on what would actually help, get in touch.
