Most Odoo implementations that go badly did not go wrong during development. They went wrong in the first three weeks, when nobody wrote down precisely what the system was supposed to do. Requirements gathering is the least glamorous phase of an ERP project and the one that quietly decides the cost, the timeline, and whether go-live feels like a launch or a fire drill.
Here is what a scope should contain before anyone opens a configuration screen.
Start from processes, not module names
The most common way requirements go wrong is a list that reads: "we need Sales, Inventory, Accounting, and HR." That is a shopping list, not a scope. It tells an implementation team nothing about how an order becomes a delivery, who approves a purchase above a threshold, or what happens when a customer returns half a shipment.
Write the processes end to end instead. Quote to cash. Purchase to pay. Hire to retire. For each one, name the trigger, the steps, the person who acts at each step, and the document that comes out the other side. The module list falls out of that naturally, and so do the gaps.
Write requirements as decisions, not wishes
"The system should handle multi-currency" is a wish. "Sales orders are issued in USD and EUR, invoices post in SAR at the rate on the invoice date, and realized FX differences go to a dedicated account" is a decision. The second can be configured, tested, and signed off. The first generates three more meetings.
A useful test: if two people read the requirement separately, would they build the same thing? If not, it is not finished yet. Vague requirements do not disappear. They resurface during UAT, when changing them is far more expensive.
Be honest about must-have versus nice-to-have
Every organization agrees to prioritize, then marks all 140 requirements as critical. The result is a scope nobody can deliver on the agreed date, so something gets cut anyway, usually late and under pressure, and usually the wrong thing.
A stricter framing works better. Ask which requirements would stop you from invoicing a customer, paying a supplier, or closing the month if they were missing on day one. Those are the must-haves. Everything else goes into a second phase with an actual date attached, not into a vague "later" that erodes trust when it never arrives.
The requirements that get forgotten
Process interviews reliably capture the happy path and reliably miss the rest. Ask about these explicitly:
- Reporting. Who needs which number, how often, and in what format. Report requirements gathered after go-live often force data model changes that should have been decided at the start.
- Approvals and access. Who may see costs, margins, salaries, or other companies' records. Access rules are a design input, not a configuration detail to be handled at the end.
- Numbering and references. Invoice sequences, project codes, and item references usually have to match a legacy convention or an auditor's expectation.
- The data cutoff. How much history moves, how open balances are loaded, and which system stays the source of truth for closed periods.
- Integrations. Banks, payment gateways, e-commerce, payroll, government portals. Each one carries its own testing effort and its own external dependency.
- Localization. Tax treatment and statutory filings for every country you operate in, delivered by Odoo's official localization modules rather than assumed.
- Languages and multi-company. Whether users work in Arabic, whether documents print bilingually, and whether inter-company transactions need to post on both sides.
Check the standard system before writing a gap
A requirement is only a gap once someone has confirmed standard Odoo cannot do it. In practice a meaningful share of items that arrive labeled as customizations turn out to be configuration: a pricelist rule, an approval setting, a report filter, a well-chosen field on an existing model.
This matters because custom code has a permanent cost. It has to be maintained, retested at every version upgrade, and understood by whoever inherits it. Standard configuration does not. Push each requirement through a fit check first, and only then decide whether it justifies development. Our business analysis service exists mainly to run that filter properly before the build starts.
Where scope should stay open
Freezing everything is its own failure mode. Some questions genuinely cannot be answered until people see their own data in a working system, and pretending otherwise produces a signed document full of guesses.
The workable middle is to freeze the process design and the integration list, then leave layout, report formatting, and dashboard content open until the first end-to-end walkthrough. Name those open items explicitly in the scope so they are recognized as deferred decisions rather than treated later as new requests.
What you should end up with
A usable scope is not a hundred-page document nobody reads. It is a process map per cycle, a numbered requirements list with a priority and a fit-or-gap verdict on each line, an integration inventory, a data migration plan, a reporting list, and a short register of the decisions still open with names and dates against them.
That package is what makes a fixed timeline credible. Without it, an estimate is a guess, and every change request becomes an argument about what was agreed. With it, the arguments happen on paper in week two instead of in production in month six, which is a much cheaper place to have them.