Industries We Serve

Nobody Budgets for Change Management

The most underfunded line item in every ERP project, and the reason so many stall after go-live

Every ERP project has a line item for software licenses. It has a line item for implementation hours, for data migration and for a small army of consultants. What it rarely has is a real line item for change management, even though change management is often the difference between a project that delivers value and one that quietly limps along for years.

Technology is the easy part of an ERP project. Microsoft Dynamics 365 will do what it's built to do. It will run finance, manage inventory and connect your supply chain the way the specification promised. The hard part is getting your people to actually work inside of it. That's not a technology problem. It's a human one, and it gets underfunded on almost every project we see.

When companies build an ERP budget, they think in categories that feel concrete: software, infrastructure, integration, testing. Change management doesn't fit neatly into any of those buckets, so it gets treated as something that will happen naturally once the system goes live. A few training sessions, an email announcement and maybe a one-page cheat sheet taped to a monitor.

That approach assumes people adopt new systems because they're told to. They don't. People adopt new ways of working when they understand why the change is happening, when they've had a chance to ask questions and have learned what benefits are gained. None of that happens through a training deck alone.

Research from McKinsey has found that a majority of large-scale transformation efforts fail to meet their goals, and the reason cited most often isn't the technology itself. It's the people side: unclear communication, insufficient leadership involvement and employees who were never brought along for the ride. ERP projects follow the same pattern.

Here's what actually happens when change management gets skipped. The new system goes live on schedule. It works exactly as designed. And then, within a few weeks, employees start finding ways around it. They export data into the spreadsheets they've always used. They keep a shadow process running because it's familiar and the new one feels slower, even if it isn't. They complain that "the system doesn't work," when what they really mean is that they never understood how to use it.

This is where a lot of executives get confused. They see low adoption and assume the software was the wrong choice, so they start looking at customizations or even a different platform. But the system isn't broken. The rollout was. Nobody explained what was changing, why it mattered or what was in it for the people doing the work every day.

The cost of this shows up gradually and it's easy to miss until it's significant. Productivity dips. Data quality suffers because people are entering information into two systems instead of one. Reports pull from inconsistent sources, and the leadership team loses confidence in numbers that should have been more reliable, not less. All of that traces back to a change management gap that could have been closed months before go-live.

Change management isn't a single event. It's a set of practices that run alongside the technical implementation from the very beginning, and it includes a few things that matter more than any others.

Leadership visibility comes first. When executives are visibly involved and consistently reinforce why the change matters, adoption improves. When leaders delegate the entire effort to IT and only show up for the go-live announcement, employees notice, and they draw their own conclusions about how important this really is.

Communication that starts early matters just as much. Employees who hear about a major system change for the first time a month before go-live have every reason to be anxious and resistant. Employees who've been part of the conversation for months, who've had a chance to give feedback and ask questions, walk into go-live day already invested in making it work.

Role-specific training beats generic training every time. A warehouse supervisor and a finance controller use D365 completely differently, and generic training that tries to cover everyone at once leaves both of them underprepared. Training built around what each role actually does in the system, with real scenarios from their own work, sticks far better.

Support that continues after go-live is the piece companies cut first, and it's the one they should cut last. The first ninety days after launch are when habits form. Companies that keep dedicated support in place through that window see adoption stabilize. Companies that pull support the week after go-live often watch adoption slide right back toward the old way of doing things.

None of this is expensive relative to the cost of the project itself, but it does need to be planned and funded, not treated as a nice-to-have that gets cut when the budget gets tight. At Hoalani, we build change management into our implementation methodology from the very first planning session, not as an afterthought bolted on before go-live. That includes a communication plan, role-based training design and a defined post-launch support period built into the project timeline from day one.

Companies that treat change management as a real workstream, with its own budget, timeline and owner, see faster adoption and effective usage, cleaner data and a much stronger return on the investment they already made in the software. Companies that skip it end up paying for the same transformation twice: once for the system, and again later for the rescue project to fix the adoption problem nobody planned for.

The technology is rarely the reason ERP projects underdeliver. The people are the reason projects succeed, so plan for them like it.

If your ERP roadmap doesn't have a real change management plan attached to it, that's worth fixing before you're further into the project. Visit hoalani.com or reach out to us at info@hoalani.com to talk through what a properly funded change management plan looks like for your organization.