An Odoo project has stalled: what to audit first

Stabilize the project record

Collect the current scope, change requests, environments, access owners, custom modules, integration diagrams and open issues. Preserve the existing work before making broad changes. If production is already operating, separate live operational incidents from unfinished project features so investigation does not disrupt the business.

Invite process owners to explain the same transaction from their perspectives. Conflicting definitions of completion often explain more than a defect count. Record disagreement explicitly instead of treating the most recent comment as an approved requirement.

Trace evidence through one complete process

Select an important workflow, such as order to delivery to invoice. Walk through representative records with the users who perform the work. Identify precisely where the expected outcome diverges from reality, then classify the cause: missing decision, inaccurate data, configuration, integration, development or training.

Keep facts separate from hypotheses. A finding should name the expected result, observed result, evidence and consequence. Avoid describing the entire implementation as broken when the evidence points to a small number of critical handoffs.

Review customization and ownership

For each custom component, ask which active requirement it supports, where its source is kept and who maintains it. Check whether a standard workflow could satisfy the need with less complexity. Odoo's custom-upgrade guidance specifically calls for evaluating custom developments against newer standard features.

Ownership matters even before an upgrade. A module with no accessible source, no defined maintainer or no repeatable installation process can become a delivery dependency that a new project schedule does not solve.

Use a decision tree before commissioning more work

Classify one blocker at a time using a reproducible example. Preserve a backup and test in a safe copy before changing live operations. Follow these branches with the process owner:

• Expected result not agreed? Resolve the business decision and acceptance test before changing code.
• The standard workflow passes with clean sample data? Investigate configuration, permissions or source data before commissioning a replacement.
• A required extension fails? Confirm the source, version compatibility, maintainer and a bounded repair test.
• A complete critical workflow still cannot meet an agreed requirement? Compare targeted repair with replacement, including migration and operational disruption.

Define what the next budget release buys

Request a short evidence pack for each proposed action: current failure, business impact, cause supported by evidence, named owner, estimate assumptions and a passing test. Track money or hours already spent separately from committed work and estimated remaining work; past spending does not prove the next change will help.

Release the next phase when its prerequisite tests pass and a responsible user accepts the result. Pause for a decision when reconciliations fail, source ownership is missing or a dependency is unresolved. A cosmetic demonstration or a new delivery date is not sufficient evidence of readiness.

Choose a bounded restart plan

Rank actions by operational impact, dependencies and evidence confidence. Decide what must be corrected before launch, what can safely follow later and what should be removed from scope. Give every blocking action an owner, a test and a decision date.

• Reconcile essential data before relying on reports.
• Resolve conflicting business rules before rebuilding automation.
• Demonstrate critical workflows with ordinary users.
• Agree the handover materials and operational support route.
• Use evidence gates for restart rather than an arbitrary new deadline.

Avoid repeating the same failure pattern

A rescue plan often fails when it adds another layer of requests without changing decision ownership. Keep a decision log and require acceptance criteria for new scope. Track unresolved business decisions alongside defects; either can block progress even if the software itself runs.