Companies spend months selecting the right ERP. They go through procurement, get board approval, sign the contract, and everyone gets excited. Then, three months into the project, the wheels start to come off.
Not because the software was wrong. Not because the consultants were bad. Because nobody had a proper grip on how the project was actually being run.
ERP project management is one of the most underestimated disciplines in the entire implementation lifecycle. It sounds boring compared to software demos and feature comparisons. But it is the single biggest variable in whether your project finishes strong or quietly fizzles out.
In a recent episode of The ABCs of ERP & Beyond, Pete Nicholson and Nirav Shah were joined by Emily Browning — an IT leader in manufacturing who has managed ERP implementations from the business side — to break down the five areas that determine project success. Here is what they covered.
1. Structure: Build the Foundation Before You Build Anything Else
Before a single workshop happens, before anyone logs into the ERP, you need to get the fundamentals right. That means defining the problem you are solving, identifying who needs to be involved, assigning roles and responsibilities, establishing governance, and understanding the risks.
This sounds obvious. It rarely happens well.
One of the most common mistakes is assembling the wrong team. Companies often default to whoever is available rather than whoever has the right combination of business knowledge and forward-thinking vision. Your best purchasing clerk might know the current process inside out, but they may not be the right person to sit on the steering committee making decisions that will shape the system for the next 25 years.
Equally important is communicating time commitment. You can identify the perfect person for a power user role, but if they do not know they are expected to dedicate 15 hours a week to the project, they will treat it as a side task rather than a core responsibility. That gap between expectation and reality is where projects start to erode.
The structure should also include cadences — weekly or bi-weekly status calls, governance checkpoints, and clear escalation paths. These are not optional. They are the guardrails that prevent one-off issues from snowballing into project-stopping problems.
2. Project Planning: Your Plan Is Your Single Source of Truth
A common objection at the start of an ERP project is that you cannot plan what you do not yet know. If you have not done requirements gathering, how can you map out the whole timeline?
The answer is: you know more than you think. You know there will be a discovery phase. You know there will be a gap analysis. You know there will be solution design, development, testing, data migration, user acceptance testing, cutover, go-live, and hypercare. You may not know every detail, but you can assign realistic timeframes to each phase, build in buffers for the things that will inevitably go wrong, and create a plan that gives everyone a shared understanding of what is coming.
The real power of the plan is not prediction — it is focus. When the project plan becomes the only agenda for your project meetings, something powerful happens. Everyone knows what they need to bring. Everyone can see what is due and what is overdue. The project manager stops being the person who chases people by email and starts being the facilitator of a team that holds itself accountable.
As one guest put it: if someone’s task was due yesterday and it is visible on the board in front of the whole team, you do not need to say anything. It is already there.
Scope Creep: Manage It, Do Not Fear It
Scope creep is inevitable. The question is not whether it happens, but how you handle it when it does.
The worst response is to ignore it. The second worst is to panic. The best approach is structured: assess whether the new request is genuinely needed for phase one or whether it can wait, take it to the steering committee, make a decision, and move on. The danger is not that something new comes up — it is that a single loud voice stalls the entire project over something that could have been a five-minute conversation.
3. Visibility: If Only the PM Knows the Status, You Have a Single Point of Failure
Project visibility means more than a status report sent to the steering committee once a month. It means the entire project team can see what is happening, what is coming next, and who is responsible for what — at all times.
Modern project management tools like Smartsheet, Monday.com, Trello, or Jira make this straightforward. Conditional formatting, automatic notifications, comment threads, and document attachments all keep information in one place. The days of managing an ERP project through email chains and Excel trackers should be behind us.
There is also a subtler benefit to visibility. When the project plan is visible and used as the basis for every meeting, it creates consistency for team members who may never have been involved in a project of this scale before. They know what to expect. They know where to look. Over time, that familiarity builds confidence and engagement — exactly what you need from the people who will ultimately make or break adoption.
4. Keeping Momentum: Decision Fatigue Is the Silent Killer
ERP projects do not usually fail on go-live day. They fail months before, during the mid-project slump when decision fatigue sets in, enthusiasm fades, and people start dragging their heels.
The companies that finish ERP projects on time have one thing in common: they make decisions and move on. Not perfect decisions. Timely ones.
Think of it like timeouts in a basketball game. You get a limited number, and each one is short. You make your adjustments and get back in the game. ERP projects need the same discipline. When an issue comes up, take a controlled pause, assess it, decide, and keep moving. If you allow unlimited timeouts with no structure, the game never ends.
The other side of momentum is defining the finish line clearly. Go-live day is not the end of the project. The first successful month-end close is a far better milestone. If you stop holding meetings and tracking progress the moment the system goes live, all those SOPs and adoption plans will quietly die.
Phase two is a useful concept, but only if it is treated as a genuine plan rather than a dumping ground for things nobody wanted to deal with.
5. Change Management: The People Side That Makes or Breaks Everything
You can have the best technical implementation in the world, and it will still fail if the people reject the system.
Change management has two halves: the technical side (system configuration, data, integrations) and the social side (people, behaviour, culture). Most project teams focus heavily on the first and hope the second takes care of itself. It does not.
The fear of exposure is real. When you take away someone’s familiar spreadsheets and legacy workarounds, you are also removing their sense of control. If the new system reveals that they have been doing something incorrectly, that is threatening — not exciting. Understanding this is essential to handling the transition well.
Practical approaches include train-the-trainer models, where power users within each department train their own teams rather than having it come from IT or the vendor. This makes the change feel less like an imposition from above and more like something owned by the people who actually do the work.
Post go-live, the biggest risk is that small changes get made without proper logging or approval. A department spots an issue, goes straight to the vendor, a tweak is made, and suddenly your SOPs and screenshots are out of date before anyone else even knows what changed. Having a formal change control process after go-live is just as important as having one during the project itself.
The Bottom Line
ERP project management is not glamorous. It does not get the same attention as feature comparisons or vendor selection. But it is the discipline that determines whether a six- or seven-figure investment actually delivers the value it promised.
The good news is that it is not rocket science. It is structure, planning, visibility, momentum, and change management — applied consistently, taken seriously, and led by someone who has the authority and the commitment to see it through.
If you are about to start an ERP project, the best thing you can do is not pick the software first. It is build the team, make the plan, and decide how you are going to run the project before a single consultant walks through the door.
Listen to the full episode: The ABCs of ERP & Beyond is available on YouTube, Spotify, Apple Podcasts, and all major podcast platforms. New episodes every two weeks.
Get in touch: Nirav Shah — nirav.shah@adcirruserp.com | Peter Nicholson — info@petenicholson.co.uk
