Why do ERP implementations fail?

Most failures trace to configuration decisions made by somebody who did not know the product well enough to know a decision was being made. The system runs, it computes the wrong numbers, and nobody finds out until a month-end, a year-end or an audit. Software defects are a small share of it. Staffing and scope are most of it.

Can a managed IT provider or digital transformation firm implement an ERP?

Some can and do it well. The question worth asking is not whether they can but how many times they have on your exact product, and who specifically will configure your chart of accounts and inventory valuation. A firm that cannot name that person and their last three projects on that product at proposal time has not staffed your project yet.

What are the warning signs during the sales process?

Nobody asked a clarifying question before quoting. Every requirement is described as possible and nothing is described as difficult. The team is named by role instead of by person. The estimate is one number rather than a range with assumptions. And nobody has said what would make them walk away.

What does a failed ERP project actually cost?

The visible cost is the fees already spent. The larger costs are the months of staff time consumed, the transactions posted on wrong configuration that have to be unwound, and a second implementation bought at full price by a business that now trusts the category less.

Where should a Calgary company start if a project is already going wrong?

Establish two things before deciding anything: whether the configuration is sound and the schedule slipped, or whether the configuration itself is wrong. Those are different problems. The first is recoverable with the same team. The second usually is not, and continuing to pay the same firm to fix it rarely works.

Why ERP Implementations Fail, and Who Was Holding the Wheel

Q: Is customisation the problem?

Customisation itself is sometimes correct. The problem is customisation bought because nobody found the native mechanism. Odoo's documentation states that a database containing custom modules cannot be upgraded until a version of those modules exists for the target release, and Odoo supports each major version for three years. So an unnecessary module becomes a recurring bill for the life of the system.

Quick answer: most ERP implementations fail on staffing rather than on software. The decisions that sink a project are configuration decisions, made early, by whoever was assigned to the account, and the damage surfaces months later at a month-end or an audit. The warning signs are all visible during the sales process.

Local Context

Calgary is unusually full of firms that could plausibly sell you an ERP implementation. Statistics Canada’s business counts for the Calgary CMA (businesses with employees, July 2025) record 11,708 professional, scientific and technical services businesses, 17.8% of the local base and the highest share of any major Canadian metro.

That is a genuine strength of this market and it creates a specific buying problem. A Calgary company looking for an ERP will get proposals from managed IT providers, digital transformation consultancies, development shops and accounting firms, alongside actual ERP implementers. Every one of those proposals will say yes.

The category is not the problem. Several of those firms do excellent work. The problem is that nothing in a proposal reliably distinguishes a firm that has configured this product forty times from a firm that will learn it on your project, and the difference does not show up until the second month-end.

The Failure Is Almost Never the Software

Enterprise software of this class works. Thousands of companies run it. When a project fails, the system is usually running exactly as configured, and the configuration is wrong.

That distinction matters because it changes who you are actually buying from. You are not buying software. You are buying a few hundred decisions about how your business will be represented inside it, and the quality of those decisions is entirely a function of who makes them.

The Four Ways Projects Actually Fail

1. A financial decision made in an operational settings screen

The expensive mistakes look like housekeeping.

Costing method is the clearest example. In Odoo 19.3 it sits on the product category, one level above the product. Odoo’s documentation states that applying a landed cost to a vendor bill requires the products on the original purchase order to belong to a category using average cost or FIFO. Leave a category on standard cost and landed costs cannot be applied at all.

An importer who discovers that after go-live has been valuing inventory incorrectly for as long as the system has run, and the correction reaches back into closed periods.

Nobody in that room made a bad decision on purpose. Somebody made a financial decision without recognising it as one, because they did not know the product well enough for the setting to look important.

2. Customisation bought instead of knowledge

Every implementation reaches a requirement the product does not answer natively. Two firms respond identically, quoting a custom module, from opposite internal states. One knew the native mechanism and judged it insufficient. The other could not find it.

The client cannot tell those apart, and the invoice is the same.

The cost arrives later and Odoo documents it. A database containing custom modules cannot be upgraded until a version of those modules exists for the target release, and standard support runs three years per major version with extended support carrying a mandatory additional fee.

So an unnecessary module is a recurring bill for the life of the system, started by a week-six decision nobody in the room heard being made.

3. The named team and the delivered team are different people

This one is structural and it implies nothing about anyone’s ability.

In a firm with eight service lines, staffing an engagement is a utilisation decision across a shared bench. The consultant assigned is the one whose availability, cost and seniority fit the slot. In a single-practice firm the bench and the practice are the same people, so the allocation question never arises.

Both models are legitimate. They give different answers to “who is configuring our general ledger,” and only one of them can answer it at proposal time.

The generalist’s standard reply is that a certified specialist is on every engagement. That is true at most national firms, and it moves the question rather than answering it. The person who decides whether to escalate to the specialist is the lead who, by hypothesis, does not know the native mechanism exists. Escalation is triggered by a suspicion, and the suspicion is the thing being bought.

4. Governance that records decisions without improving them

Stage gates, a steering committee, a PMO and formal sign-off produce a record that somebody approved the costing method. They contain no mechanism for knowing whether the approved method was right.

This is why a project can be immaculately managed and still fail. Strong method genuinely prevents coordination failures, which produce delay, are visible while they happen, and are recoverable. It does nothing about configuration failures, which produce a system computing wrong numbers, surface months later, and cost in proportion to how long they ran.

A methodology designed for a large programme also carries a governance overhead that a forty-person Calgary company funds out of the same budget that would otherwise buy configuration hours.

The Warning Signs, All Visible Before You Sign

None of these require technical knowledge to spot.

Nobody asked a clarifying question before quoting. A complex operation priced without a single question was priced against an assumption.
Everything is possible and nothing is difficult. A proposal with no hard parts has not been read properly.
The team is named by role. “A senior consultant and a technical lead” is a staffing plan that does not exist yet.
The estimate is one number. A single figure on an undefined scope is a negotiating position with a risk premium inside it.
They have never walked away from a deal on fit. A firm with no disqualifying criteria will not apply any to you.
The demo ran on their data. Vendors demo their strengths. You need to see your own exceptions.

The Eight Questions

Put these to every firm, including the incumbent if a project is already running.

How many implementations of this exact product have you completed, and how many are live and running a business today?
Name the person who will configure our chart of accounts and inventory valuation. Their last three projects on this product, and what else they are on during ours.
Tell us about the last three customisations you talked a client out of, and the native mechanism you used instead.
What in this product have you been burned by? Name a version.
Across your last five projects on this product, how far did the final invoice land from the signing estimate, and what caused the widest gap?
Of clients you implemented two or more years ago, how many are on a currently supported version, and who paid for the upgrade?
What would make you tell us this product is the wrong answer?
What is the smallest piece of paid work we could buy from you before committing to the rest, and what is its price?

Question three is the one that cannot be answered without the underlying knowledge, which is why it belongs on every shortlist call.

When the Generalist Is the Right Firm

An honest guide has to mark this, because a buyer who ignores it will choose worse.

Buy breadth when the platform is not chosen yet and you need neutral selection advice. When the ERP is one of several systems moving at once and sequencing across vendors is the binding constraint. When there is no internal IT function to own the seams. When the real problem is that nobody can agree on one process. When procurement requires insurance limits and audited financials a small firm cannot carry.

Every one of those has the same shape: the binding constraint sits outside the product. Once the platform is chosen and configuration is the work, the constraint has moved inside it.

If It Is Already Going Wrong

Establish which problem you have before deciding anything, because the two look identical in a status report.

A schedule problem means the configuration is sound and the dates slipped. Recoverable, usually with the same team, usually by cutting scope in phase one.

A configuration problem means the system is being built on decisions that are wrong. Continuing with the same firm rarely works, because the firm would have to find an error it could not see the first time.

The test is specific rather than a judgement call. Take one finished transaction, follow it from order to ledger, and check whether the numbers it produced are right. Do the same for a month-end close. If the numbers are correct and late, you have a schedule problem. If they are wrong, you have the other one.

Disclosure: Calgary Biztech is published by Solvync Inc., an Odoo implementation partner based in Calgary. The section below describes the publisher's own service and its links are marked as sponsored. The analysis above is sourced to Odoo's documentation and Statistics Canada and can be checked against both.

About the publisher, and what a takeover involves

Calgary Biztech is published by Solvync Inc., an Odoo implementation partner based in Calgary, Alberta. Solvync implements Odoo and does not sell managed IT, web development or a broader transformation practice, which places it in one of the two categories this guide compares.

Part of its work is taking over Odoo projects that stalled under a previous implementer. That work starts with the configuration audit described above rather than with a proposal, because a takeover priced before anyone has checked whether the numbers are right is the same mistake repeated at a higher price.

If a project is already running and the numbers look wrong, the eight questions above are the ones to put to the incumbent and to Solvync on identical terms. A supplier who dislikes the questions has answered one of them.

How to Choose an Odoo Implementation Partner covers the decision before a contract exists.
Calgary Business Software Planning Guide covers the sequencing before a shortlist.
Taking Over a Stalled ERP Project covers the recovery itself in detail.