10 ERP implementation mistakes that sink projects.

Every ERP failure post-mortem blames a different villain — the software, the budget, the timeline — and almost all of them are wrong in the same way. Pull apart a stalled SAP rollout, a Dynamics project quietly written off, or an Odoo implementation that has drifted back to spreadsheets, and the technology is rarely the actual reason. The causes repeat, project after project, vendor after vendor, and nearly all of them are about how the project was governed, not what it was built on.

That is genuinely useful, because it means every failure mode below is knowable in advance, and preventable with discipline rather than a bigger budget. These are ten mistakes that sink ERP projects regardless of which vendor's name sits on the licence, grouped by where they tend to strike, followed by how we structure delivery at Knova to keep each one from happening, the same discipline set out in full in our Odoo implementation guide.

Getting the foundations wrong, before configuration even starts

These three mistakes happen before a single screen gets configured, and they are the hardest to undo later, because everything else in the project is built on top of them.

• 1. Buying the software before mapping the processes. The failure symptom is a signed licence and a go-live date agreed in the same meeting that first uses the word process. Months later, the team is bending the system to match a workflow nobody wrote down, because nobody studied how the business actually operates before choosing what would run it. The fix is unglamorous and non-negotiable: a documented process study before a contract is signed, so the build is measured against the business, not the other way round.
• 2. No single internal owner with real decision authority. The symptom shows up in every steering meeting: the same question gets asked three times because the person who answered it last time was not able to make it stick. Decisions bounce between departments, get reopened after being closed, and the partner ends up managing internal politics instead of building the system. The fix is naming one senior owner before kickoff, with the authority to decide and the seniority to make it hold.
• 3. Migrating dirty data and trusting it anyway. Duplicate customers, stock counts that were wrong before the migration and stay wrong afterwards, chart-of-accounts entries nobody can explain — the old warning was garbage in, garbage out, but ERP makes it worse: garbage in, gospel out, because a number looks true the moment it appears on a clean dashboard. The fix is a proper cleansing and reconciliation pass before cutover, with the business, not only IT, signing off that the migrated data is actually correct.

Getting the build wrong, during configuration and go-live

Once the foundations are set, the build stage has its own way of sinking a project: decisions made for short-term comfort that cost more once the system is live.

• 4. Customising what should be configured, and configuring what actually needs custom work. The symptom is a system that breaks on every upgrade because a standard screen was rebuilt in custom code to preserve a habit a small process change would have solved for free. The opposite failure is just as costly: forcing a genuinely unique workflow into a standard field it does not fit. The fix is a partner who tries configuration first, argues for the cheaper path even when custom code pays more, and reserves development for where the business is genuinely different.
• 5. A big-bang go-live with no parallel run or phasing. The symptom is a single cutover weekend where every module, branch, and user switches over at once, and Monday morning becomes a crisis desk instead of a working day, because the one weekend meant to catch every gap never had time to catch any of them. The fix is a parallel run or a phased rollout, critical modules first, so surprises surface while there is still something to compare against.
• 6. Skipping user training until the final week. The symptom is a training session squeezed in days before go-live, delivered as a generic feature tour rather than a walkthrough of each user's own job, so the knowledge is gone by the time anyone actually needs it. Adoption then fails quietly, not with a complaint, but with staff rebuilding a spreadsheet because it is faster than asking how the new screen works. The fix is role-based training that starts weeks before go-live and continues after it, on real data, in the sequence people will actually use.

Getting the partnership wrong, and paying for it after go-live

These mistakes are made before a contract is even signed, and the cost only becomes visible months later, once the initial excitement has worn off.

• 7. No named support path after go-live. The symptom appears about six weeks after launch: the implementation team has moved to its next project, the only contact is a general ticket inbox, and a question that would take ten minutes on-site sits unanswered for a week while the business quietly reverts to the workaround it always had. The fix is a named support path agreed before go-live, not sourced afterwards under pressure, with a defined response time and a face the business recognises.
• 8. Choosing a partner on price alone, with no accountability written down. The symptom is a proposal chosen because it undercut the other two, with no committed go-live date, no named consultants, and no consequence if either slips, so when they do, the business has no leverage beyond an unpleasant conversation. The fix is judging proposals on committed dates, named seniority, and what the partner stands to lose if delivery slips, not the lowest number on the page.

Losing control once the project is already running

The last two mistakes are not one-time decisions but slow leaks — the kind of drift nobody chooses on purpose and everybody notices too late.

• 9. Treating reporting as an afterthought instead of designing it upfront. The symptom surfaces at the first month-end after go-live: finance needs a report the system was never configured to produce, so someone exports raw data into a spreadsheet to rebuild the report the project was meant to retire. The fix is defining month-end and board outputs before configuration begins, then building the chart of accounts, cost centres, and analytic tags to produce them natively, so reporting is a click, not a rebuild.
• 10. Letting scope creep ride without a change process. The symptom is a project that keeps absorbing one more small thing with no discipline on how each one gets in, until the go-live date has quietly moved three times and nobody can point to the single decision that caused it, because there were fifty small ones instead. The fix is a written change process from week one: every addition gets scoped, costed, and given an explicit yes from the named owner against the original date, so growth becomes a decision, not a drift.

How Knova structures against each of these

None of the ten mistakes above are Odoo problems, SAP problems, or Dynamics problems — they are project-governance problems that surface through whichever system happens to be running, which is why our Odoo implementation service is built around discipline first and software second. A named consultant is on-site on a fixed day every week, so decisions get made in the room instead of drifting across email threads for a fortnight, and delivery is phased against agreed milestones rather than staged as one weekend.

Executive support is a condition of the engagement, not a hope. We ask for one named owner with real decision authority before the project starts, and we hold the project to that person rather than renegotiating scope with whoever answers the phone that day. Training is built into the timeline from week one, not crammed into the last one, and month-end reporting requirements are agreed before configuration begins, not discovered at the first close.

A support path is named and active from the day the system goes live, through our support and AMC service, so year one does not quietly become the year the old workarounds creep back in. The commercial structure closes the loop: you see your own system running on your own data before you pay a fee, and if we miss the go-live date we agreed, you walk away owing nothing, the sharpest incentive we know to get ownership, data, and discipline right the first time.