Why is implementing an ERP so hard?
We have a great job: we get to make people's working lives better by automating the routine and making companies more productive. Few products have that kind of real impact on the people who use them.
But implementing an integrated management system is as hard as it is impactful. Odoo connects every department to every other one, which means big changes, and a lot of users counting on you to improve how they work.
of proprietary ERP implementations fail
the share of SMBs that successfully deploy a full proprietary management system
Source: Odoo's official implementation methodology.
The cost and complexity are simply more than most companies can absorb. That recurring failure is exactly our opportunity to stand out.
By making implementations smooth, predictable, and affordable, we make a real difference in the market.
Core concepts
The philosophy behind every decision in the project, from scoping to go-live.
Who owns what
| Responsibility | Owner |
|---|---|
| Defining the business need (what, and why) | Client |
| Deciding how to implement it (how) | Project team |
| Challenging requests to confirm they are worth it | Project team |
- Owner
- Client
- Owner
- Project team
- Owner
- Project team
The core idea: you are the experts in your business; we are the experts in the product. The client describes the problem. We propose the best solution.
Simplicity first
Complexity doesn't grow linearly. It grows with the square of the number of customizations.
5 customizations aren't 5 units of complexity. They're 25.
From this principle come our rules:
- Fewer meetings, faster decisions: meetings don't ship projects
- The fewest possible decision-makers: the fewer people a decision needs, the faster it moves
- Minimal custom development: every extra customization adds risk and cost
- On-site work is for training only: site visits are valuable for training and change management, not for technical implementation
What does a successful project look like?
A single definition of success: it keeps decisions from drifting and the team focused on the goal.
The plain definition
A successful project = delivered on time + on budget + on a system that actually works.
| Not a success metric | The real success metric |
|---|---|
| Client satisfaction during implementation | Delivered on time |
| Number of features shipped | Delivered on budget |
| Upselling services before go-live | A system running for real, in production |
- Not a success metric
- Client satisfaction during implementation
- The real success metric
- Delivered on time
- Not a success metric
- Number of features shipped
- The real success metric
- Delivered on budget
- Not a success metric
- Upselling services before go-live
- The real success metric
- A system running for real, in production
The top priority of a successful project is getting users live on the system, on time and on budget. Most failed implementations ultimately surface as delays, budget overruns, or a system that never reaches effective production use.
Why isn't client satisfaction a success metric?
Because satisfaction swings throughout the project:
Enthusiasm runs high
Anxiety, sometimes frustration
Satisfaction comes back, and climbs
For the first three months I didn't enjoy working with the project leader: he challenged every request I made. Later I realized it was all for the good of the project. He often found better solutions than what I'd asked for. Now, even after go-live, I call him before any operational decision.
The takeaway: chasing moment-to-moment satisfaction pulls focus away from what the project is actually for.
Why don't we upsell before go-live?
- It's 7x easier to sell services to an existing client after go-live than to win a new one
- Every pre-go-live sale erodes trust: the client starts questioning your priorities
- A fast go-live is a competitive edge: it builds a base of happy clients who buy more later
Roles
Who does what: on the implementation side and on the client side.
On the implementation side
Project Leader
The project's primary decision-maker, three roles in one person:
As project manager
- Builds the project plan and tracks it
- Keeps the focus on what actually matters
- Involves the client's SPoC at every step
As business analyst and product expert
- Decides how each requirement gets implemented
- Challenges client requests and manages expectations
- Writes technical specifications when needed
The golden rule: the project leader doesn't say "yes" to everything. They propose the best solution, and the client accepts it or pushes back.
Project Director
On large or high-stakes projects, a project director works alongside the project leader. Their job:
- Reporting project status to the client's senior management
- Monitoring how efficiently the project is running
- Managing decision-makers' expectations
They don't work on the project day to day. They oversee it from a wider vantage point.
App Expert
A deep specialist in one app (Accounting, Warehouse, Manufacturing, and so on). Not part of the day-to-day project team. They're called in at critical moments to review the proposed solutions and give an independent opinion.
Developer
Most small companies (under 50 users) need no custom development at all. The developer steps in only when the business genuinely requires development that cannot be handled any other way.
On the client side
Single Point of Contact (SPoC)
The project's key partner on the client side. One person with decision-making authority, working closely with the project leader.
Their responsibilities
- Collecting and evaluating project requirements
- Training end users, with the project leader's support
- Becoming the in-house Odoo expert and supporting their colleagues
What makes a good SPoC
- Genuinely available to the project
- Empowered to decide: no running to their manager for every detail
- Accepted and respected by their colleagues
Warning: an SPoC who isn't available, or lacks real authority, is an early warning sign that the project will stall. Fix it from day one.
I once ran two similar projects for two companies under the same owner. On the first, the SPoC was an operations manager. The project wrapped up successfully in a few months. On the second, the SPoC was the CEO himself: always busy, every decision took days. That project turned into a nightmare. The only difference: the quality of the SPoC.
Supporting roles (on large projects)
- Steering committee: the client's decision-makers plus the project director, tracking the methodology and the success metrics
- Key Users: experts in their departments who help define requirements and test deliverables
- Sponsor: usually the CEO or CFO; champions the project in front of the team and makes the strategic calls
Implementation phases
Four phases with fixed time shares, each with a clear goal and measurable deliverables.
How the time is split
Gap Analysis (GAP)
Business analysis, gap identification, plan and budget
Kick-Off
Aligning the team on the methodology + core training
Implementation
Back-to-back cycles: analyze, build, validate, train
Go-Live
End-user training + fixing what breaks
Goal: understand the client's current reality and build a solid plan before committing to any cost.
What the client gets
- A map linking their business needs to the system's features
- A project plan with timeline and cost
- A proof of concept (demo) for hands-on validation
Gap Analysis steps
- A meeting with the decision-makers to define goals and risks
- Workshops with the key users in every department
- Documenting the gaps and the plan
- Review by an independent App Expert
- Presenting the findings to the client, with a working demo
Golden tip: always start by understanding how the client works today, not how they want to work tomorrow. Current reality sets the minimum you must cover, and it lets you challenge requests on solid ground.
Goal: align everyone on the methodology and lock in a solid plan.
This phase sets the course for the whole project. Everyone must understand:
- How we'll work together
- What each side is empowered to decide
- What gets delivered, and when
Tip: if you spot a problem with the timeline or with how the client understands the requirements, raise it now, not later. Delay only compounds problems.
I was handed a project that had to ship in 12 days: 5 full apps. I told the CEO straight: "This project is impossible in that time. But if there is one shot at success, the conditions are: 100% standard system, and you do exactly what I say, no debate." He agreed. We delivered in 9 days. The right kick-off is what made the impossible possible.
Goal: build the system in back-to-back weekly cycles.
Each cycle consists of
Project leader with the key user
Set up the system
The SPoC tests and signs off
On the feature just delivered
Data migration
- Import Master Data only
- Avoid importing historical records unless absolutely necessary: they cost significant time and effort for limited value
- Never hold up Go-Live over data quality: cleanup can happen after launch
Validation and training
- Have the SPoC run the workflows themselves: watching isn't enough
- A user who drives the system with their own hands learns faster and deeper
Goal: run the system on real work and real data.
Critical advice
- Don't postpone Go-Live except in truly exceptional cases: delay raises costs and kills momentum
- Be on site for the first few days if there's resistance to change
- Move fast when a problem appears: every launch has hiccups; what sets you apart is how quickly you fix them
Just before Go-Live, I met a CEO who was scared and wanted to push it back six months. I told him: "Go-Live is always hard. Even if we wait six months, problems will still surface. The difference is that we'll fix them fast. Postponing just adds new costs and new risks."
After Go-Live · the second deployment
One month after Go-Live, the project leader revisits the parking lot of deferred requirements.
Here's the interesting part: typically 50% of the deferred development turns out to be unnecessary once people have used the system for real, while new requirements surface that were never in the original plan.
Which confirms it: a fast launch with a sensible scope beats a slow launch with a massive one.
Implementation challenges, and how we handle them
Resistance, expectations, and custom development: the three biggest obstacles and how we manage them.
Resistance to change
The truth: people resist change by nature, from the newest hire to the founder. There is no such thing as a small change.
| Common mistake | What to do instead |
|---|---|
| Ignoring the unconvinced | Invest time in showing them the benefits. "Sell" them the solution through training and hands-on examples |
- Common mistake
- Ignoring the unconvinced
- What to do instead
- Invest time in showing them the benefits. "Sell" them the solution through training and hands-on examples
Change is always perceived as cost and risk. And risk is accepted only when the payoff clearly outweighs it. Don't say "it's simple". Show the real benefit.
Managing client expectations
Right before signing, the CEO told me: "This project is life or death for my company. Promise me everything will go smoothly." I answered: "No. This project is very hard. We will hit plenty of problems. But in the end your company will be better off, and I need you, as CEO, to back the project when your team complains."
Two years later he called me. The project had slipped 12 months, but he said: "I did what you asked: I backed the project the whole way and never criticized the system in front of my team." The result: Go-Live two months later. Had I reassured him with "everything will be fine," he'd have pulled his support on day one.
The lesson: honesty early on is what protects trust in the long run.
Custom development: when to accept, when to refuse
Why do we keep it to a minimum?
- Every customization = 25% in annual carrying cost (~17% maintenance + ~8% upgrades)
- Complexity grows with the square of the number of customizations, not linearly
- A development estimated at 10 days often takes 12, and gets priced at 8
The decision framework: 4 questions, in order
| Question | If the answer is "no" |
|---|---|
| Is it truly necessary? (Does the client actually do this today?) | Refuse |
| Is the cost worth it? (Multiply by 2–3 for maintenance, then weigh against the time saved) | Refuse |
| Is the gain big enough? (10 transactions/month × 10 minutes = two hours a month!) | Refuse |
| Is there another way? (An internal policy, a standard feature, an off-the-shelf app) | Use the alternative |
- If the answer is "no"
- Refuse
- If the answer is "no"
- Refuse
- If the answer is "no"
- Refuse
- If the answer is "no"
- Use the alternative
The rule: accept custom development only if the answer to all four questions is "yes."
A client asked me for a custom report he'd been building in Excel every week. Before agreeing, I asked: which numbers does the CEO actually need? It turned out he only needed the balances of a few analytic accounts, which Odoo shows out of the box. One question saved 10 days of development.
Writing a good specification
When development is genuinely needed, a good spec has three parts:
The use case (what?) and its rationale (why does this client specifically need it?), two to three paragraphs.
The proposed solution in Odoo (how?), with screenshots or visual mockups where possible.
What the developer needs to keep in mind.
The rule: a good spec is short, visual, and well organized. Length is not quality.
Data and metrics
Realistic expectations for historical imports, and the maturity ladder for project leaders.
Data imports: realistic expectations
Historical imports (past years' records)
Many clients ask for them. First, ask yourself:
- Could this data stay in the old system, or in an Excel file?
- How often will it actually be looked up?
- What's its strategic value over the next 2–4 years?
The SPoC insisted on importing every historical record from her old system. I explained that it would take weeks and eat into the budget. I proposed: let's launch in 3 weeks without the history, and add it later if we ever need it. She agreed. Three months after Go-Live she sent me a thank-you note: "I haven't needed a single old record. Not once."
How do you measure your project's success?
This is the maturity ladder for project leaders. Use it to gauge the level of your implementation partner:
- One project delivered on time and on budget
- 4+ apps implemented within a reasonable timeframe
- A project delivered under its original budget
- Odoo certification passed at 70%+
- Successful projects in 3 different industries
- Migration from a legacy ERP in under two months
- A full system implemented for 500 users
- 10 consecutive projects delivered on budget
- Migration from a legacy ERP in under 4 weeks
The principles, in short
Five principles that govern every decision in the project.
- On time, on budget = success That is the only metric. Everything else is detail.
- Standard before custom, always Every customization adds risk and cost. Start standard; build custom only when there is truly no alternative.
- One solution, not a menu of options We propose the best answer; the client accepts it or pushes back. Multiple options slow the project down.
- Honesty from day one A client who knows the challenges backs the project. Empty promises destroy trust.
- Common sense over any rule If a rule is doing harm, break it and record why. The methodology is a tool, not a cage.