Client Requirements Changed During an Odoo Implementation? Here’s What to Do

You’re in week six of an Odoo implementation. Sales, Inventory and Accounting are configured, the chart of accounts is mapped, UAT starts on Monday. In a config review, the warehouse manager, who was in none of the blueprint workshops, says:

This is fine, but we scan lots at putaway and every pallet label has to carry the lot number and the customer PO. That’s how we’ve always worked.

Nobody is being difficult. The requirement is real, it’s operationally necessary, and it genuinely was never captured. What you do in the next twenty minutes decides whether this becomes a controlled change or the first line in a go-live post-mortem.

Why a late requirement costs more than the work it describes

In ERP work the build hours are usually the smallest part of the bill. A requirement that arrives after the blueprint is signed drags a tail behind it.

• Configuration decisions already made downstream.Moving a warehouse from one step to multi step receipts changes operation types, routes, and every stock move already modelled in the test dataset.
• Customisation carries a maintenance cost. An inherited view or a custom QWeb report isn’t a one off. It’s a line item in every future version upgrade, so it should be priced as a commitment, not as a task.
• Test data and UAT scripts stop being valid. A changed process means new scenarios, re-run test cases and re-tested integrations.
• Training and documentation drift. The user guides and the session your team already prepared now describe a process that no longer exists.
• Cutover assumptions shift. New master data, like lot tracking on existing stock, has to be collected, cleaned and loaded before go-live, usually by the client, who has a day job.

That’s why the professional answer is never a flat “that’s out of scope” and never a reflexive “no problem”. It’s an impact analysis.

Run the impact analysis before you take a position

Four questions, in order.

1. What is the business requirement underneath the request? Traceability from receipt to delivery is a requirement. “Print the lot number on the pallet label” is one implementation of it. Standard Odoo lot tracking may already satisfy the requirement at a fraction of the cost, and finding that out is the most valuable thing you do all week.
2. Configuration, Studio, or a custom module? The cost curve between those three is steep, and so is the long term upgrade exposure. Say which one you’re proposing and why.
3. What else does it touch? Modules, integrations, reports, permissions, the data migration plan, the training plan, the cutover checklist.
4. Is it required for go-live, or can it be phase two? This question resolves more late requirements than any other. Most of what arrives in week six is genuinely needed, just not on day one, and often better designed after users have lived in the system for a month.

Classify it explicitly, against the blueprint

Judge the request against the signed blueprint or the statement of work, never against the last workshop conversation. There are three outcomes, and you should name which one applies.

• In scope. The requirement is described in the blueprint and this is simply how it gets configured. No change request, no extra cost.
• Clarification of scope. The blueprint covers the intent but the detail was underspecified. Some of these you absorb as professional judgement. Some are large enough to need a change request. Say which, and say why, in one sentence.
• New requirement. Additional process, module, customisation or integration. It gets a change request every time, including when it’s small and including when you plan to do it free of charge. A zero cost change request still protects the timeline and still records the decision.

That last point deserves a moment. On ERP projects, the change with no cost but a two week schedule impact is far more dangerous than the expensive one, because nobody feels the need to approve it.

Document the decision, not just the task

A defensible change record contains:

• The requirement as the business stated it, and who stated it.
• The business justification. The compliance rule, the customer demand, the audit finding.
• The options you considered, including the standard Odoo option you rejected and why. This is what separates a consultant from a supplier.
• The recommended approach and its effort estimate by role.
• The impact on cost, timeline, go-live date and future upgrade maintenance.
• What’s explicitly excluded, and any assumption the estimate rests on.
• The decision, the approver and the date.

Quantify the impact honestly, including the parts you dislike quoting

Consultancies routinely under quote late requirements to keep the peace, then absorb the overrun. It’s a false economy, and the client learns the wrong lesson: that changes are free.

Quote the full picture.

• Functional analysis and development hours, by role.
• Re-testing and re-running affected UAT scenarios.
• Training and documentation updates.
• Additional user licences, third party connectors or infrastructure.
• Ongoing upgrade maintenance for any customisation, stated as an annual expectation.
• The effect on the critical path, specifically on the go-live date, since in ERP that date is usually tied to a fiscal period, a contract end or a legacy system switch off.

Name the client side effort too. Data cleansing, key user availability for retesting, sign-off time. A change that needs forty hours from the client’s own team and looks free on your invoice is not free, and saying so early builds more credibility than any discount.

Obtain explicit approval from the project sponsor

The person who raises a requirement is rarely the person accountable for the budget. On an ERP project, approval has to come from the project sponsor or the steering committee, whoever owns the go-live date and the budget line, and it has to be recorded against the specific estimate and the specific new date.

Make declining easy and neutral. A sponsor who can say “defer to phase two” in one click will answer today. A sponsor who has to write a paragraph explaining themselves will answer next week, while your consultant sits idle.

Execute only after approval, and keep the register current

Starting work on an unapproved change is how implementations lose control of scope and budget at the same time. The register stops matching reality, and every estimate after that is built on sand.

The change register is also the best instrument you have in a steering committee meeting. “We’re three weeks past the original date” is an accusation. “We’re three weeks past the original date because of eleven approved changes, seven of them from the warehouse team after the blueprint, here they are with the dates you approved them” is a conversation about how the client wants to run the rest of the project.

What it looks like in practice

A lightweight control layer between you and the client

Most Odoo consultancies already have this process on paper. What they don’t have is a fast way to run it. The change request lives in a Word template, the approval lives in an email thread, the register lives in a spreadsheet that one person updates, and by month four none of the three agree with each other.

StayScoped is a thin layer over exactly that step. Write the change, state the cost and the new date, send one link. The sponsor opens it without an account, approves or declines, and the decision is stored with their name and a timestamp against the project. Your register stays current because approving is what updates it.