How to scope an Odoo project so the quote survives contact with reality

Every disputed ERP invoice we have ever been shown started the same way: a scope that both sides read differently and neither side wrote precisely. The fix is not a longer contract. It is a different kind of document.

Scope as outcomes and gaps, not modules

A scope that says sales, inventory and accounting prices nothing. Those are product names. They do not say what happens when a customer returns half an order, who may change a price, which company owns which cost, or what the system has to produce at month end.

Write it the other way round. Map the process, list every gap between how you work and how the software behaves, and give each gap one of four dispositions:

• Configure. Standard behaviour covers it once set up.
• Customise. Code is needed, and it gets its own estimate.
• Change the process. The business adapts, deliberately, with a named owner for the change.
• Leave out of scope. Written down as excluded rather than silently omitted.

Each item carries a number. That list is the contract. Anything raised after sign-off is quoted as a change request rather than absorbed into the timeline, which is the only honest way to keep a fixed price fixed. Absorbed work is what turns a fixed price into a dispute.

Price per item so the list can be trimmed

The reason for per-item estimates is not accounting neatness. It is that a client who needs to cut 15 percent should be able to cut 15 percent of the scope, rather than defer the whole custom block to a phase two that never gets funded.

It also changes the conversation about each item. A request with a number next to it gets defended or dropped on its merits. A request inside a lump sum never gets examined at all.

The four questions that shrink a scope for free

Before pricing anything, put every custom request through these.

What breaks in the business if the standard behaviour is used instead? Requests raised in week one are usually descriptions of the old system. Ask teams to run the standard flow first. A real share of the original list gets withdrawn without argument.

Is this a reporting request wearing a customisation costume? A large share of custom requests are really about a number somebody cannot find. A configurable dashboard closes many of them with no code at all.

Should it be a setting rather than a constant? Anything a manager might reasonably want to change should be configurable. Settings cost a little more up front and save a support ticket every time the number moves.

Does something maintained already cover most of it? If a maintained module covers the requirement, buying it is cheaper than building and keeps you off a private fork. We say so even where it means less work for us.

What must never be quoted up front

Three pieces of work should be quoted after an assessment, not before, and a vendor who quotes them blind is guessing at your expense.

Version upgrades. Two things move in an upgrade and they move differently: the database has to be converted so older records still mean what they meant, and the custom code has to be ported to a version that has changed underneath it. A quote written before anyone has read the custom modules is a guess. The assessment inventories every installed module with its source, checks which third-party modules exist for the target version and which have no successor, grades the porting effort per module, and identifies features that changed behaviour between your version and the target. Then it can be priced. That is why our migration work prices the assessment as a small fixed piece and carries its findings into the upgrade quote.

E-invoicing. Quoted per entity and per document type in scope, after a data readiness check, because master data that was perfectly adequate for a printed invoice is often missing the fields the output requires, and there are usually more of them than anyone expects. Profiling first turns the biggest unknown into a count. The e-invoicing service is built around that order.

Payroll. Quoted per entity and driven by the number of salary structures and the complexity of the rule book rather than by headcount. Two thousand employees on three structures is a smaller job than eighty employees on eleven. The parallel run is part of the scope and not an optional extra, because a payroll build that has not been reconciled has not been finished. That is the entry condition on our payroll setup work.

The estimate is only as good as what the client supplies

Half of every overrun we have investigated traces back to inputs that were assumed rather than agreed. Put them in the document as obligations, with names against them:

• A named decision maker per function with authority to change a process, not just describe it.
• An export of the legacy data, plus someone who can explain what the odd columns mean, because the meaning of a column is rarely written down anywhere.
• The chart of accounts and opening balances, signed off by whoever closes your books.
• Sample documents you want back out of the system: a quotation, an invoice, a purchase order, a delivery note.
• Credentials and a technical contact for every system that has to stay connected.
• Real user time for testing and training, blocked out in calendars in advance.
• A go-live date that avoids your busiest weeks and your period close.

If the proposal does not list those, the timeline in it is fiction, however good the estimate is.

Say what is out of scope in writing

Soft edges are where goodwill goes to die. Ours are stated on every proposal: hardware procurement, subscription fees and third-party licences, writing your accounting policy or setting your approval limits, data your previous vendor will not or cannot export, process re-engineering beyond the agreed map, ongoing support once hypercare closes, and content work such as product photography and translated copy.

None of that is a refusal to help. It is a refusal to leave it ambiguous.

Fixed price or time and materials

Fixed price where the scope is settled, with milestones and a change-request route for anything new. Time and materials for discovery work and for ongoing customisation where the backlog is expected to move, ideally with a monthly ceiling you set.

The one thing we will not do is quote fixed-price against a scope nobody has written down. That quote is either padded, in which case you overpay, or it is optimistic, in which case the argument arrives in month three. Neither is a good outcome and both are avoidable with a week of proper discovery.

Reports are where scope quietly doubles

Worth its own heading because it happens on nearly every project. Ask for the short list the business genuinely cannot close a month without, treat that as a go-live condition, and park the rest. Teams that revisit the parked list a quarter later usually delete most of it, because half the reports on it were compensating for something the new system does differently.

What a good scope document looks like

One page of process narrative per function. A numbered gap list with a disposition and a number against each line. A separate list of client obligations with owners. An explicit out-of-scope section. A change-request route with a rate. Milestones tied to deliverables you can inspect, not to elapsed weeks.

That document is boring to write and it is the difference between a project that lands and a project that argues. If you want to see how the phases and the published bands fit together before you commit, the pricing page sets it out, the implementation service describes the sequence, and a framed consultancy engagement is the right shape when the real question is still which project to run. If you are holding someone else’s quote and want it read as written, that is a request we get often and are happy to take: talk to us.