ERP Implementation Methodologies: A Practical Guide

Picking the software is only half the job. How you implement it decides whether your ERP pays for itself or becomes the system everyone works around. This guide covers the two main implementation methodologies, how to choose a partner, the risks to manage, the people side of change, and what happens after go-live.

So you have run a proper evaluation and chosen your enterprise resource planning (ERP) software. You are not done yet. ERP projects have a reputation for running over time and over budget, and the cause is almost always planning and people rather than the software itself.

How should you go about implementing ERP software?

With a lot of planning. An implementation plan should exist before you sign for the software, not after. It should answer three questions: how the project will be run, who from your side is involved, and what "done" looks like on go-live day.

Most implementations move through the same broad phases:

• Process analysis
• Process organisation
• Configuration
• Training
• Testing
• Go-live

Even with a great team, some projects take far longer than others. A big part of the difference is the methodology used to govern the work. There are two main approaches: Waterfall and Agile.

The Waterfall methodology

Waterfall is the traditional way to implement ERP software. Each stage flows into the next, and a stage is finished and signed off before the following one starts.

A Waterfall ERP implementation usually looks like this:

• Discovery
• Planning
• Design
• Development
• Testing
• Go-live and deployment
• Support and maintenance

Its strength is predictability. Scope, budget and timeline are agreed up front, which suits businesses with stable, well-understood processes. Its weakness is that problems found late, usually in testing, are expensive to fix because everything before them has already been built.

The Agile methodology

Agile accepts that requirements change during a project. Instead of one linear run, the work is split into short sprints. Each sprint ends with testing and feedback, and the plan is adjusted before the next one starts.

Because issues surface every few weeks rather than at the end, the team can respond to them while they are still small. The trade-off is that the final scope is less fixed, so budget control relies on strong prioritisation and an engaged client team.

Which methodology should you pick?

There is no one-size-fits-all answer. Waterfall is easier to understand and suits a static environment. Agile suits a business that is changing while the project runs.

In practice many projects blend the two: a fixed plan for scope, data migration and go-live, with shorter build-and-test cycles for configuration, reports and integrations. Whatever the label, ask any partner to show you how their method handles change requests, testing and sign-off, because that is where projects go wrong.

Free guide: compare the eight ERPs Australian mid-market businesses shortlist in 2026. Download the ERP Selection Guide

Choosing the right implementation partner

The methodology only works if the team running it is right for you. When comparing partners, look at:

• Experience in your industry. Choose a partner who has implemented for businesses of your size and complexity, in your sector.
• Team size and bandwidth. A very large partner may not prioritise you. A very small one may not have the people to cover a mid-sized project, or absorb unexpected changes.
• Depth on your platform. Some partners sell many products but have a thin team for the one you are buying. Ask who will actually work on your project.
• A proven methodology. Look for a structured approach with concrete timelines, plus a clear process for handling change.
• Post-implementation support. Ask how support works: how you contact it, response times, support hours and how issues are escalated.

When proposals arrive, check what is included and what is quietly missing:

• Responsibility for data conversion
• User acceptance testing
• User training
• Project management
• Report and dashboard creation
• Integration with your other systems
• What internal resources you are expected to provide
• Post-implementation support
• Pricing, and what triggers extra cost

The internal resources line matters more than most buyers expect. Many proposals assume you can release staff for the project. Most small and mid-sized businesses cannot, so make sure it is spelled out. For a typical mid-market scope, a MYOB Acumatica implementation runs roughly two to six months. For more on this decision, read why your ERP partner matters more than the platform.

Getting it right the first time

A well-run implementation starts with an honest risk assessment. There are three risks to manage:

• Software risk. Is this platform the right long-term fit for the business?
• Implementation risk. Does the partner have the expertise to deliver what they promise?
• Internal risk. Can your team commit the time and people the project needs?

The projects that go well tend to share the same habits:

• An internal project champion with the authority to make decisions
• Thorough testing before go-live, not after
• Clean data migrated into the new system, rather than old problems carried across
• Key stakeholders involved from the start
• Clear expectations on budget and timeline
• Ongoing training after launch

Get it wrong and you hear the two most expensive sentences in ERP: "this is harder than what we had before" and "we have spent all this money and still are not seeing the benefits".

What to expect during the project

Michael Pendred, a director at Stratus Consulting Group with more than 20 years in ERP, sets expectations with clients in six points:

1. Adjust your ways, because the software will not. No system is tailor-made for your business. Adapting some processes to the software is part of the deal.
2. Reports are not magic. Expect to invest time in customising reports. They rarely come out perfect straight out of the box.
3. There is always a stage 2. You will not get everything done in the first release. Plan for a second phase rather than cramming it all into go-live.
4. Bugs come with improvement. Vendors ship new features and fixes constantly, and occasionally break something. Test before every upgrade.
5. Big jobs take time. Large reports and data runs in cloud software can be slow. Schedule them rather than wait on them.
6. Your consultant is on your side, but not psychic. Nobody knows your business as well as you do. Treat the project as a partnership.

Change management: the people side

An ERP project is as much about people as technology. Elise Webb, a Prosci change management specialist at Stratus, focuses on four things:

• Prepare your team. Explain what is changing and why, and assess the impact on each role, so people understand how the new system helps them.
• Spread the workload. Leaning on one person risks burnout and puts the project at risk if they leave. Share responsibilities across the team.
• Build a knowledge base. Document processes and system know-how, and get several people proficient, so staff turnover does not stall the project.
• Form a strong project coalition. Regular updates, clear feedback channels and open communication keep everyone aligned and catch concerns early.

Learn more about change management at Stratus.

After go-live: training never really finishes

Go-live is the start of the journey, not the end. Cloud ERP platforms such as MYOB Acumatica and Wiise ship new features and compliance updates throughout the year, and your team needs to keep up to get full value from them.

• Advanced training. Once people are comfortable with the basics, deeper training unlocks the functionality you are already paying for.
• New user training. New starters often miss the training their predecessors had. A formal onboarding process for new users keeps usage consistent.
• Refresher sessions. Periodic refreshers after major releases keep the team current with new features.
• A training plan. Assess skill gaps, match training to different skill levels, keep it hands-on, and review it regularly.

Businesses that keep investing in training get more out of the same software. Businesses that stop at go-live usually end up back in spreadsheets.