Quick answer: Use a fixed scope when your processes are clear and mostly standard, use agile sprints when your needs will change as people learn Odoo, and for most mid-size companies use a hybrid: a fixed-price analysis and a fixed-scope phase 1 for the must-have flows, then short sprints after go-live. Whatever you choose, Odoo's own Implementation Methodology guide says the priority is to get users onto Odoo on time and within budget, with as little custom development as possible.
Choosing an Odoo implementation methodology decides how your budget is fixed, how change requests are handled and how much time your team must give. This guide compares fixed-scope, agile and hybrid Odoo project plans, using Odoo's official Implementation Methodology guide (version 05, July 2024) as the reference, and explains how we plan Odoo projects at Peanut Square.
The Odoo implementation methodology in Odoo's own guide
Odoo's guide was written for its own project leaders, and it is a useful baseline for any Odoo project plan. It splits a project into phases with these relative durations:
ROI analysis (about 10%): analysis, phasing and budget. For most small and mid-size companies the guide folds this into the kick-off.
Kick-off (about 5%): align stakeholders on the method and finalise the plan, scope and phasing.
Implementation (about 80%): a series of short cycles of analysis, configuration, development, validation and key-user training. The guide says the team should deliver functionality every week.
Go-live (about 5%): end-user training and bug fixes. The guide notes this can take 10% to 15% on larger projects because of heavier change management.
Second deployment (variable): broaden the scope or add the custom features that were postponed.
Three ideas from the guide shape everything below. First, a project succeeds when it is delivered on time and on budget. Second, custom development is a last resort, because it adds cost, delays and future upgrade work. Third, nice-to-have features can wait until after go-live. The guide notes that, a month after go-live, about half of the developments requested earlier are typically no longer needed.
Fixed-scope Odoo implementations
In a fixed-scope (often fixed-price) Odoo implementation, the scope, price and date are agreed in writing before work starts. You sign off one plan and the partner delivers against it.
Where it works:
Your processes are clear and close to standard Odoo, for example sales, purchase, inventory and invoicing for a trading company.
Finance needs one approved number before the project starts.
The number of apps and integrations is small and known.
Where it hurts:
The scope is fixed before your team has used Odoo, so requirements are guessed rather than tested.
Every change after sign-off becomes a change request with its own estimate, which can slow the project down.
To protect a fixed price, the analysis phase grows. Odoo's guide warns against long analysis phases and against importing years of data history before go-live, because both eat budget without helping users start.
Agile or phased Odoo implementations
In an agile Odoo implementation, you work from a prioritised backlog in short cycles, often two weeks. Each cycle configures, tests and trains a small set of flows, and the next cycle is planned from what users learned.
Where it works:
Your needs will change once people see Odoo, for example a manufacturer moving from spreadsheets to work orders for the first time.
You want early quick wins. Odoo's guide recommends turning the plan into a series of quick wins so users start working in the system early.
You can give a key user (the guide calls this person the single point of contact, or SPoC) regular time to test and decide.
Where it hurts:
Budget certainty is lower. You know the cost per sprint, not the final total.
Without a firm go-live date, sprints can drift. The guide warns that delaying go-live exposes the project to extra risk and cost, and that it is usually better to go live quickly even if everything is not perfect.
It needs steady time from your team in every cycle, not just at the start.
Hybrid: phase 1 fixed, then sprints
For most mid-size Odoo projects we recommend a hybrid. It follows Odoo's own phasing closely:
Fixed-price discovery and gap analysis. Map your current processes, pain points and data, and decide which needs standard Odoo covers.
Fixed-scope phase 1. Only the flows you cannot run the business without. Everything else goes to a backlog.
Go-live. Train end users and fix issues quickly.
Sprints after go-live. Work through the backlog in short cycles, reviewing each item again with real usage data.
Phase 2 and beyond. New apps, nice-to-have features and integrations that proved worth it.
This hybrid Odoo implementation methodology gives finance a firm number for the part that matters most, keeps the go-live date protected, and moves the uncertain items to a point where your team knows Odoo well enough to judge them.
How should change requests be managed in an Odoo project?
Change requests are normal. What matters is a clear, quick way to decide on them. Odoo's guide suggests four questions for any custom request: is it really necessary, is it worth the cost of building and maintaining it, is the gain significant enough, and can the same goal be met another way? We turn that into a five-step process:
Log the request with the business reason and who asked for it.
Check standard Odoo first. Configuration or Studio often solves it without code. Our guide to Odoo Studio vs custom development explains where the line sits.
Estimate the impact in hours, cost, effect on the go-live date and future upgrade effort. Odoo's upgrade documentation warns that a database with custom modules cannot be upgraded until those modules are available for the target version.
Decide: now, next sprint, phase 2, or no. The guide splits development into what is needed before go-live and what can follow later.
Re-plan and sign off so the budget and date stay visible to everyone.
How we plan an Odoo project
When we plan an Odoo project, we keep the plan short and visible. These are the steps we follow and recommend to any buyer comparing Odoo partners:
Start from how you work today. Odoo's guide puts the current situation ahead of future wish lists, because it defines the minimum scope. We review your current documents, reports and screens before proposing anything.
Choose the model per phase, not per project. Discovery and phase 1 are usually fixed; later phases often run as sprints.
Name one decision-maker on each side. The guide recommends limiting stakeholders to speed up decisions and training key users early.
Protect the go-live date. Master data is imported for go-live; full history is imported only when it is truly justified, and preferably after go-live.
Keep custom code for real gaps. We configure standard Odoo first, use Studio for simple changes and write custom modules only where needed, so future upgrades stay manageable.
Ask your team to own training and documentation. The guide recommends that key users train end users and write the user manual in their own terms, which also proves they have tested the flows.
If you are still choosing a partner, our checklists on how to find an Odoo partner near you and choosing an Odoo team in Ahmedabad list the questions to ask about any project plan, and our guide to choosing an Odoo implementation partner in India covers what to expect from a partner.
How Peanut Square can help
Peanut Square is an Odoo Learning Partner based in Ahmedabad, Gujarat, founded in 2017. We have developed 90 Odoo modules and delivered 100+ projects, and our team includes an Odoo-certified consultant. Our Odoo clients include Renite Vitrified, Woodleaf and Madhav Solar. Through our Odoo implementation service, we can run a discovery, propose a fixed-scope phase 1 and a backlog for later sprints, and set up a change request process your team can follow.
Planning an Odoo project and unsure which Odoo implementation methodology fits? Talk to us: https://www.peanutsquare.com/en/contact
About the author: Nishant Patel, CTO, Peanut Square
Nishant leads technology at Peanut Square, an Odoo Learning Partner founded in 2017 and based in Ahmedabad, Gujarat. The team has developed 90 Odoo modules, delivered 100+ projects and includes an Odoo-certified consultant.
Sources
Odoo, Implementation Methodology: the ultimate guide to successfully implement Odoo projects (V05, July 2024), chapters 2, 4 and 5: https://www.odoo.com/documents/content/nElGuToBRwODc2Z6F9gHpwo2e674
Odoo 20.0 documentation, Upgrade: https://www.odoo.com/documentation/20.0/administration/upgrade.html
Odoo 20.0 documentation, Studio: https://www.odoo.com/documentation/20.0/applications/studio.html
Is fixed-scope or agile better for an Odoo implementation?
Neither is better for every project. Fixed scope suits clear, mostly standard processes and a finance team that needs one approved number. Agile suits needs that will change as people learn Odoo. For most mid-size companies a hybrid works well: a fixed-price analysis and a fixed-scope phase 1 for must-have flows, then short sprints after go-live.
How long does each phase of an Odoo implementation take?
Odoo's Implementation Methodology guide gives relative durations: about 10% for ROI analysis (folded into the kick-off for most small and mid-size companies), 5% for kick-off, 80% for implementation in short cycles, and 5% for go-live, or 10% to 15% on larger projects. A second deployment follows with variable duration. Actual calendar time depends on scope.
How should change requests be handled in an Odoo project?
Log each request with its business reason, check whether configuration or Studio can solve it, estimate hours, cost, date impact and upgrade effort, then decide whether it goes in now, in the next sprint, in phase 2, or not at all. Odoo's guide suggests asking whether it is really necessary, worth its build and maintenance cost, significant enough, and whether another approach meets the same goal.
What is a fixed price Odoo implementation?
In a fixed price Odoo implementation, the scope, price and date are agreed in writing before work starts. It gives budget certainty, but scope is fixed before your team has used Odoo, so later changes become change requests with their own estimates. It works best when processes are clear and close to standard Odoo.
Why should custom development wait until after go-live?
Odoo's methodology guide calls custom development a last resort because it adds cost, delays and upgrade work, and it notes that about half of the developments requested before go-live are typically no longer needed a month after go-live. Building only what is essential first keeps the go-live date safe and lets real usage decide the rest.
