The first thing that surprised me about running an ERP implementation was how little of the actual work was about the software.
I led a full rollout at a company I worked at as the sole project manager, 11 workstreams across 6 project phases. By the time you get to go-live, you have made hundreds of decisions that had almost nothing to do with which system you selected. What processes you are standardizing. Whose workflows change and whose do not. Who has approval authority in the new system that they did not have before. Who loses the informal workarounds they had been relying on for years. Those are not technical choices. They are organizational ones that happen to require a configuration in a piece of software.
Scope creep starts before the project does.
When word gets out that an ERP is coming, every department sees an opportunity. The logistics team wants a feature. Finance wants a custom report. Manufacturing wants the system to handle a workflow that was never in the original brief. Adding things feels low-cost because the system is large and interconnected. It never is. Every addition means more configuration, more testing, more training, more places where something can break at go-live. The scope expands while the timeline does not.
The hard part is that most of these requests are reasonable. The logistics team genuinely needs that feature. Saying no to legitimate requests from people who will use the system every day creates friction that does not disappear. I said no more often than felt comfortable. Looking back, that was probably the right call more often than I gave it credit for at the time.
Translating what people need into what a system can do is harder than it sounds, and the gap between them is where most ERP projects fail quietly.
Users think in terms of what they do. Systems are configured in terms of how they work. A procurement manager who says "I need to flag a PO for re-approval if the price changes by more than 5%" is describing a workflow they built intuitively over years. Turning that into a system configuration requires understanding both what they are asking for and what the software can actually support, and those two things are often close but not identical. The gap gets bridged with a workaround. The workaround becomes the process. Three years later nobody remembers what the original requirement was, and the system has accumulated enough workarounds that the next change is harder than it should be.
Change management is not a phase of the project. It is the project.
Every piece of implementation guidance will tell you change management is important. Almost none of it is specific about what that means in practice. What it means is: getting users trained before go-live, not during. Running user acceptance testing with the people who will actually use the system, not just the technical team. Managing expectations carefully about what day one looks like versus what the system looks like after six months of use. Communicating often, even when there is nothing definitive to say.
The political dimension is this: ERP implementations redistribute visibility. Some departments get clearer reporting than they have ever had. Some lose the informal flexibility they used to work around broken processes. The people who had the most to gain from the lack of structure are often the loudest critics of the new system. Not because the system is wrong. Because it makes things visible that were not before, and visibility creates accountability.
That is not a technical problem. No configuration change resolves it.
What actually helped was keeping a live project command center with module coverage, UAT status, risk register, and issues log visible to all stakeholders throughout the project. Running UAT with real data, not synthetic test cases. Fixing issues that came up in UAT before go-live instead of logging them for later. And treating go-live as the beginning of the real project rather than the end of the implementation.
The system is never done on the day you switch it on. The distance between what was configured and what the business actually needs closes over time if you work at it. The projects that fail are the ones that treat go-live as the finish line, hand it over, and move on.