1 Oct 2026 · 8 min read
Implementing a new ERP system is one of the biggest projects a business will take on. It touches finance, operations, inventory, sales and reporting, and it changes how your people work every day. Done well, it gives you one source of truth and a platform to grow on. Done poorly, it runs over time, over budget and under expectations.
The good news is that most ERP problems are predictable, and avoidable. In our experience, the single biggest factor in a smooth project is what happens early, in the elaboration phase. This is where requirements are explored, decisions are made and scope is agreed in writing. Get this right and the rest of the project has a firm foundation. Skip over it and you invite the most common ERP headache of all: scope creep.
In this post we walk through what to expect at each stage of an ERP implementation, why the elaboration phase deserves your full attention, and how to use it to keep your project on track.
Every implementation partner uses slightly different names, but most ERP projects follow the same broad path. Knowing the stages in advance helps you plan your team’s time and understand what is being asked of you at each point.
The dividing line that matters most sits between elaboration and build. Before it, changes are cheap. After it, every change has a real cost.
The elaboration phase is where a high-level vision becomes a detailed, agreed plan. During discovery, you told us what you want the system to do. During elaboration, we work through exactly how it will do it, process by process, with the people who will use it.
Expect a series of structured workshops with your finance, operations, sales and warehouse teams. Together we map your current processes, walk through how the new system handles them out of the box, and identify the genuine gaps. Each gap then needs a decision: change the process, configure the system, or build something custom.
By the end of elaboration, you should have:
That last point is the one that matters most. The elaboration phase is not finished when the workshops end. It is finished when the right people have read the design and agreed to it in writing.
It can be tempting to rush elaboration. Workshops feel slow, the documents are long, and everyone is keen to see the new system running. But every decision deferred here does not go away. It turns up later, during build or testing, when it is far more expensive to deal with.
A change agreed on a whiteboard in week three costs a conversation. The same change discovered in user testing can mean reworking configuration, rewriting integrations, re-running data loads and retesting. In the worst cases it moves the go-live date.
Scope creep is the gradual growth of a project beyond what was originally agreed. It rarely arrives as one big change. It arrives as a steady stream of small, reasonable-sounding requests:
On their own, each request seems minor. Together they stretch timelines, drain budgets and exhaust the project team. Worse, they often arrive late, once people can see and touch the system, which is exactly when change is most costly.
Scope creep thrives on ambiguity. If nobody wrote down what “inventory management” includes, then every new idea can be argued to be part of it. A signed-off elaboration phase removes that ambiguity. It gives everyone a clear, shared baseline to measure new requests against.
With that baseline in place, a new request is no longer a debate about what was meant. It becomes a simple question: is this in the agreed scope or not? If it is not, it goes through a change control process where its value, cost and impact on the timeline are weighed openly. Some changes will be worth making. Many can be parked for a phase two. Either way, the decision is deliberate rather than accidental.
Clear agreement also protects relationships. When expectations are written down and signed off, there are far fewer surprises and disagreements between your team and your implementation partner later on.
Here is what we encourage every client to do to get elaboration right.
With a signed-off design in place, the project moves into delivery. Here is what the remaining stages typically look like.
Build and configure. The system is set up to match the agreed design. Any approved customisations, integrations and reports are developed. You will usually see regular demonstrations so you can confirm things are on track.
Data migration. Your data is extracted, cleaned and loaded into the new system, often over several trial runs. Your team plays a key role in checking the results.
Testing. Expect several rounds, from system testing by the project team to user acceptance testing (UAT), where your own staff run real-world scenarios. Because the requirements were agreed at elaboration, testing checks the system against a clear standard rather than shifting opinions.
Training and change management. Staff learn the new processes and system before go-live. Good communication throughout helps people understand why things are changing, not just how.
Go-live. The switch-over, usually planned for a quieter period such as a month end or a weekend. Expect a short period of adjustment as people settle in.
Post go-live support. A period of close support, often called hypercare, to resolve early issues quickly. After that, the focus turns to optimisation and to any phase two items you parked along the way.
If you remember one thing, make it this: agree it early, write it down and sign it off. A clear, shared understanding of scope is the best protection your project, your budget and your go-live date can have.
