Why ERP Projects Fail, and What to Do Differently

An ERP replacement is the largest software project most companies ever run, and the failure pattern is remarkably consistent. It is almost never the software. It is that the project was defined as an IT task when it is really a change to how the business records what it does.

Nobody owns the data

The chart of accounts has grown for fifteen years. Three customers exist four times each. Half the stock codes describe products that were discontinued in 2019. Migration is where projects lose their months, because cleaning this is business work that no department volunteers for. Name an owner per data set at the start, with a deadline, and treat it as the critical path — because it is.

• Chart of accounts, agreed by finance before anything is configured
• Customers and suppliers, deduplicated with VAT numbers verified
• Stock items, with the discontinued ones actually removed
• Opening balances, reconciled to a date the auditor accepts

The 20% that is genuinely yours

Around eighty per cent of what a company needs is the same as every other company: invoices, bills, banking, VAT, payroll, stock. Configuring that is not where the value is. The remaining twenty per cent — the approval rule, the pricing logic, the report the owner reads on a Sunday — is what makes the system worth using. Spend the budget there and take the standard behaviour everywhere else.

Every customisation of the standard eighty per cent is a cost you pay again at every upgrade, forever.

Pick a go-live date the calendar allows

Do not go live in the week of a month-end close, during Ramadan operations, or the month a VAT return is due. Go live at the start of a period with both systems running in parallel for one full close. The parallel period feels wasteful right up to the moment it saves you.

And train people on their own screens with their own data. Generic training on a demo company is the reason staff quietly keep the old spreadsheet for another year.