Skip to Content

The Discovery Meeting Isn’t About Gathering Requirements — It’s About Challenging Them

December 28, 2025 by
Arij Shahla
If your ERP discovery meeting feels productive because you filled 20 pages of “requirements” — that’s exactly why your project is at risk.

Most ERP projects don’t fail because of bad software.
They fail because discovery was treated like note-taking instead of decision-making.

And I see this every week with Odoo and ERP implementations across MENA and Lebanon.

The real problem no one wants to admit

Discovery meetings are often run like shopping trips.
Sales module.
Inventory module.
Manufacturing. Accounting. HR.
Everyone nods. Everyone feels heard.
And nothing meaningful gets challenged.
I’ve sat in sessions where:
  • A manual approval step existed “because the old system had it”
  • Three departments owned the same decision — and none could explain why
  • Customizations were requested to protect broken processes instead of fixing them
Here’s the uncomfortable truth:
If discovery doesn’t create tension, it’s not doing its job.
ERP discovery is not about agreeing with stakeholders.
It’s about helping them realize what shouldn’t exist anymore.

What high-performing ERP teams do differently

Instead of collecting requirements, they interrogate them.
They ask questions that feel uncomfortable — but save months of rework later:
  • Why does this step exist today? Not “how do we configure it,” but why it survived this long.
  • Who truly owns this decision end-to-end? Not who executes it — who is accountable when it goes wrong.
  • What business outcome are you actually optimizing for? Speed? Control? Cash flow? Compliance? Pick one.
  • What problem are we solving — and what happens if we don’t? If nothing breaks by removing it, it’s probably not a requirement.
  • What’s the ROI if we skip this entirely? Every process has a cost. Few have a return.
  • Is this a system gap — or a process habit? ERP should expose inefficiencies, not hide them with custom code.
This is discovery that changes the project before it starts.

What this looks like in practice

A recent example.
A Lebanese manufacturer came into discovery convinced they needed heavy Odoo customizations for approvals, reporting, and production planning.
Instead of accepting the list, we challenged it.
We removed duplicated approvals.
Clarified ownership across operations and finance.
Reframed reporting around decisions, not dashboards.
Result?
  • Scope reduced by ~30%
  • Implementation timeline shortened by weeks
  • Zero “must-have” customizations left — only strategic ones
Same ERP.
Different discovery.
Completely different outcome.


Because ERP success doesn’t start with configuration.It starts with the courage to ask better questions.


Arij Shahla December 28, 2025
Share this post
Archive
If Everyone Owns the Process, No One Owns the Outcome