Why You Must Clearly Define Odoo Projects from Day One – And How to Avoid the Common Conflicts

Introduction:

In Odoo projects, things usually start off fine. But after a couple of weeks, the client suddenly asks,

"Where's that screen I mentioned?"

"Why isn’t this feature working the way I imagined?"

And boom — conflict.

Why does this happen?

Because there was no clear agreement from the beginning.

No BRD (Business Requirements Document).

No signed scope.

Just meetings and phone calls that everyone thought they understood.

First: What is a BRD, and Why Is It So Important?

Think of a BRD like a contract — but for features.

You sit with the client, and you write down everything:

• How the system should work
• What screens and reports they need
• Who does what
• Any specific customizations or calculations

Once it’s all documented, the client reviews and signs off.

Why?

So later, if there’s a misunderstanding, we can go back and say:

"Hey, this is exactly what we agreed on."

How Should an Odoo Project Be Done — Step by Step

1. Requirements Gathering:
   Sit with the client. Understand their current processes. Ask questions. Take notes.
2. Create a Clear BRD:
   Write all details down — no guessing, no assumptions.
   
   
3. And if any changes are made to the BRD after it’s signed, a new version must be created (e.g. BRD v2, BRD v3…) and signed again by the client.That way, there’s always a clear record of the latest approved requirements — no confusion, no "I thought it was included
4. Write a Scope of Work (SOW):
   Based on the BRD: What’s included, when it’ll be delivered, and for how much.
5. Start the Work — But Only What’s in the BRD:
   Anything new? It’s a separate request.

What If the Client Asks for Something New During the Project?

Here’s the real test.

Two types of new requests show up:

• Nice-to-have Features (Optional):
  Not critical. You can offer them later, with a separate cost.
• Critical Features (Must-have):
  Pause. Think. Is this something we missed in the analysis?
  Or is it something the client forgot to mention?
  • If our team missed it → We do it at no extra cost.
  • If the client forgot or changed their mind → We prepare a change request with the cost and timeline.

What If There's Fault on Both Sides?

This happens too.

• If the implementation team made a clear mistake → We take responsibility.
• If the client was unclear or changed their mind → They cover the cost.
• If both sides missed it → We talk, negotiate, maybe share the cost.

How to Avoid These Issues from the Start

✅ Talk to everyone involved — not just the manager

✅ Document everything clearly — even the small stuff

✅ Build a simple prototype to visualize the system

✅ Never start work without signatures

✅ Let the client review and sign off each phase

What About Additional Costs?

Simple rule:

Anything new = New cost

The agreement must include that:

• Any new feature or request will be quoted separately
• No work starts without client approval
• Price per hour or per feature must be clear

Conclusion:

If the beginning isn’t clear, don’t be surprised when problems pop up later.

The BRD and signed scope aren’t “extra paperwork” — they are your protection.

And they protect the client too.

Always follow this rule:

“If it’s not written, it doesn’t exist.”