- ERP projects rarely fail on the software. Odoo, NetSuite, MYOB Advanced and SAP Business One all cover the functional ground an SME needs. They fail on scope, sequencing and adoption.
- A blowout is usually three things at once: cost above quote, time past deadline, and a system people quietly work around.
- Scope creep is not one big decision. It is forty small ones nobody priced.
- Staged delivery caps the damage. Big-bang cutover concentrates it. Comparison table below.
- Migration is the most feared step and the most controllable one. Map, test load, reconcile, then switch.
- Ask any partner the seven questions at the end. If they cannot answer the change-process one and the migration one in specifics, expect a blowout.
What counts as a blowout?
Three forms, usually together.
Cost. Quoted at $40k. Invoiced at $140k. The extra was real work. It was just never priced before it was built.
Time. Six months becomes eighteen. The business runs two systems in parallel the whole way, which costs more than either. Double data entry, two sets of reports, and a finance team reconciling between them every month.
Adoption. Delivered on budget and on time, and half the team still runs the spreadsheet. This is the expensive one and it never appears in a project report.
A definition worth being clear on: scope creep is work added after the scope was agreed, without a corresponding change to price or timeline. It is not the same as a change of mind. Changes of mind are normal in an ERP build, because you learn things. Unpriced changes are the problem.
Why does scope blow out?
Because discovery keeps happening after the build starts.
The sequence is almost always the same:
- Scoping workshops run with managers. Managers describe the process as designed.
- The build starts against that description.
- A user sees the first demo and says the real process has a step nobody mentioned.
- The step is small. Everyone agrees to add it.
- Repeat forty times.
- The invoice arrives.
No single request in that list is unreasonable. Each one takes a day or two. Nobody prices them individually because each feels too small to stop the project for. At a typical Australian implementation rate, forty un-priced days is most of a six-figure variation nobody chose.
The businesses this happens to are rarely disorganised. They are usually running Xero or MYOB plus a stack of point tools, something like Cin7 or Unleashed for inventory, a separate CRM, spreadsheets holding the joins together. Every one of those joins is a process that exists in someone's head and in no document.
Is it the software's fault?
Rarely.
Odoo covers sales, inventory, manufacturing, projects and finance in one platform. So do NetSuite, MYOB Advanced, SAP Business One and Microsoft Dynamics 365 Business Central. For an Australian SME between $2M and $50M turnover, the functional gap between these is usually small. The cost gap is not, but that is a different article.
The gap that matters is between how the business actually works and how it was described in a room.
Two sources:
- Undocumented process. The thing one person does every Thursday that holds a step together. It is in their head, not in any document.
- Requirements gathered from the wrong people. Managers know the intended process. The people doing the work know the actual one, including the workarounds they invented when the intended one stopped fitting.
If your requirements came only from managers, your scope is a description of a business that does not exist.
Staged delivery or big-bang cutover?
A big-bang cutover means the entire new system replaces the entire old system on one date. Staged delivery means the system goes live in usable pieces, each one reviewed before the next is scoped.
| Staged delivery | Big-bang cutover | |
|---|---|---|
| First value to the business | 8 to 12 weeks | End of the project |
| Commitment at signing | Stage one only | Whole program |
| When problems surface | One stage at a time, in a small blast radius | All at once, in production |
| Fallback if something fails | Previous stage still running | None. You are live |
| Scope control | Re-set with real information at each review | Fixed against assumptions made at month zero |
| Change cost | Priced per stage, visible | Absorbed into a variation at the end |
| Training load on staff | Spread across stages | One large event, low retention |
| Best suited to | Most SMEs, complex operations, first ERP | Small scope, hard external deadline, high internal capability |
Big-bang is faster on paper. It is also where the eighteen-month projects come from, because every problem surfaces at once, in production, with no fallback.
What does staged delivery look like in practice?
We run builds as an OODA loop. Observe, Orient, Decide, Act. A decision framework built for situations where the picture changes while you are acting on it, which is exactly what an ERP build is.
- Observe. Sit with the people doing the work, not just the org chart. Map what actually happens, including the workarounds.
- Orient. Set the system up around the decisions the business makes. Margin by product, cash position, job cost, stock value. Design the reporting first, then the workflows that feed it.
- Decide. Cut the smallest useful stage. One that goes live on its own and delivers something usable.
- Act. Build it, go live, review it with real users, then decide the next stage with what you learned.
Four rules make it hold:
- Stage one scope in writing, at a fixed price. No stage two commitment required.
- Every change priced before it is built, logged in a change register the client sees.
- A go-live at the end of each stage. Not one cutover at the end of everything.
- A review after each stage, where scope for the next one is set with real information instead of assumptions.
What happens to ten years of data?
This is the number one reason businesses stay on a system they have outgrown. It is also the most controllable part of the project.
The order matters:
- Map. Decide what comes across and in what shape. Not everything should. Ten years of dead contacts and obsolete SKUs is not history, it is weight.
- Test load. Load it into a copy of the new system. Nothing touches live.
- Reconcile. Check the numbers on the copy against the numbers in the old system. Trial balance, stock on hand by value, open invoices, open purchase orders, opening balances. They match or you go back to step one.
- Cut over. Only after the numbers reconcile.
Done in that order, migration is the least dramatic part of the job. Done as a single load on go-live weekend, it is the reason the project is remembered badly.
Why do people stop using the system after go-live?
Because the new system is harder than the workaround for at least one person, and nobody owns fixing that.
What prevents it:
- Every process has a named owner inside the business, not just inside the project.
- Training on the actual daily task, not a feature tour.
- A fortnight of active support after each go-live, where problems get fixed rather than logged.
- One place to report a problem, with visible resolution.
Adoption is not a training event. It is the first month.
What should you ask before you sign?
Seven questions. The answers tell you more than the quote does.
- What exactly is in stage one, in writing, and what is explicitly out?
- What happens when we ask for something outside that scope? Show me the change process.
- How many go-lives are there, and what does the business get at each one?
- Who did you talk to during scoping: managers, or the people doing the work?
- What is the migration plan, and when do I get to check the data on a copy before we switch?
- What does support look like in the first month after go-live?
- What is the fixed price for stage one, and what is the estimate range for everything after?
If a partner cannot answer 2 and 5 in specific terms, the project will blow out. Not because they are dishonest. Because there is no mechanism stopping it.