Why Projects Don’t Finish on Time
The Moving Targets, Hidden Workloads, and Decision Bottlenecks That Derail ERP Implementations
The Odoo demonstration went well. Management saw the possibilities, approved the proposal, and agreed on a launch date.
Then the questions started.
“Can we add another approval step?”
“Could this also handle our other branch?”
“We have reorganized the department. Can we change the workflow?”
Meanwhile, finance has not submitted its opening balances. Sales has not validated its customer records. The project coordinator is waiting for management to approve a process change.
The launch date moves. Frustration grows. Someone asks: Why is the implementation taking so long?”
Technical difficulties and weak implementation practices can certainly cause delays. But business owners should also examine the organization surrounding the project: how it defines requirements, allocates people, and makes decisions.
An Odoo implementation connects information, workflows, and responsibilities across departments. Its schedule depends on those connections working.
Three documented ERP cases—two Odoo implementations and one cautionary example from another platform—help illustrate why.
“Could this also handle our other branch?”
“We have reorganized the department. Can we change the workflow?”
Meanwhile, finance has not submitted its opening balances. Sales has not validated its customer records. The project coordinator is waiting for management to approve a process change.
The launch date moves. Frustration grows. Someone asks: Why is the implementation taking so long?”
Technical difficulties and weak implementation practices can certainly cause delays. But business owners should also examine the organization surrounding the project: how it defines requirements, allocates people, and makes decisions.
An Odoo implementation connects information, workflows, and responsibilities across departments. Its schedule depends on those connections working.
Three documented ERP cases—two Odoo implementations and one cautionary example from another platform—help illustrate why.
1. Scope Creep: When Every Possibility Becomes a Requirement
Odoo’s breadth can turn an implementation workshop into a wish-list session.
A company initially agrees to implement sales, inventory, and accounting. During demonstrations, managers discover more possibilities: automated purchasing, additional dashboards, CRM, and customized approval rules.
Each request may be sensible. Collectively, they can transform the agreed project.
Even when functionality already exists in Odoo, introducing it may require process decisions, data preparation, access configuration, testing, and training. “The feature is available” does not mean “the work is already done.”
One principle behind the Agile Manifesto offers a useful reminder:
“Simplicity—the art of maximizing the amount of work not done—is essential.”
- Principles behind the Agile Manifesto. 1
For management, this means deliberately choosing what deserves attention now.
Case 1: G&L Systemhaus—Launch the Core, Then Improve
According to Odoo’s published customer story, German IT company G&L Systemhaus worked with implementation partner RATOCON to introduce Contacts, Sales, and Accounting as its core foundation.
The approach emphasized an initial usable system, standard functionality wherever suitable, a dedicated contact person, and weekly status updates. Odoo reports that the company went live less than nine months after the first workshop.
The G&L team also reported:
“By automating and consolidating several applications in Odoo, we have achieved time savings of approximately 40% in invoicing.” 2
This vendor-published account does not establish whether every original schedule commitment was met. It does illustrate a practical approach: deliver a defined operational foundation, then expand.
The management lesson: A first release can create measurable value without containing every desirable capability.
How to protect your Odoo scope
Define the first release around business outcomes: processing orders, controlling stock, issuing invoices, and producing dependable financial information.
Maintain a separate backlog for improvements. For every addition, ask:
- What business problem does it solve?
- Must it be available at the first launch?
- What other work will it affect?
- What changes in budget, workload, or delivery date?
Management can then defer the request, replace another requirement, add resources where useful, or accept a revised schedule.
An approved addition must come with an approved consequence.
2. Scope Collapse: When the Original Plan Stops Matching the Business
Scope creep expands the project. A more disruptive problem occurs when its foundations change.
Call it scope collapse: a practical description of situations where the agreed scope no longer provides a dependable basis for implementation.
Sometimes ambiguity is the cause. A Statement of Work says “configure purchasing approvals,” but nobody has agreed on approval limits, exceptions, or responsible officers.
Sometimes the business changes. Departments merge, employees move, and new functions emerge. A workflow approved last month no longer matches the organization that will use it.
The project may need substantial redesign. But restarting everything without assessing the impact can discard work that remains useful.
Dwight D. Eisenhower captured the importance of continuing preparation when he repeated an Army saying:
“Plans are worthless, but planning is everything.” 3
Applied to implementation, the value lies in understanding assumptions and dependencies well enough to revise the plan intelligently.
Case 2: XLG—A Defined Rollout Within a Complex Group
Odoo’s published XLG case describes a Belgian services group with more than 9,000 employees, several business lines, conflicting databases, and different ways of working.
Working with partner Nalios, XLG pursued a common system and more consistent processes. Planning and payroll requirements introduced challenges, but the account reports that Odoo became operational in its main branch, XLG Facility, in six months.
That distinction matters: the reported milestone concerned the main branch, rather than a complete simultaneous deployment across every business line. 4
The management lesson: For a complex organization, define a manageable deployment boundary and specify exactly what the milestone covers.
The case does not document “scope collapse.” Its relevance is the challenge of establishing common processes across varied operations—a challenge organizational changes can intensify.
How to keep the scope grounded
Before configuration, validate major workflows using realistic transactions.
For each process, establish who initiates the work, who approves it, what information is required, which exceptions matter, and how completion will be accepted.
When a reorganization occurs, assess the affected processes, access rights, data, reports, training, and tests. Then decide whether the project needs a limited adjustment, a redesigned workflow, or a revised baseline.
Change the parts whose assumptions have changed. Preserve the parts that remain valid.
3. The Invisible Workload: When Implementation Becomes Everyone’s Second Job
An implementation budget may account carefully for consultant hours while barely recognizing the client’s contribution.
Employees must explain processes, clean records, investigate inconsistencies, test transactions, and provide feedback. Their regular responsibilities continue.
Finance still has closing deadlines. Warehouse staff still have deliveries. Sales still has targets.
Project work loses to urgent operational demands.
The resulting delay spreads through dependencies: configuration waits for information, testing waits for configuration, and training waits for stable workflows.
Employees must explain processes, clean records, investigate inconsistencies, test transactions, and provide feedback. Their regular responsibilities continue.
Finance still has closing deadlines. Warehouse staff still have deliveries. Sales still has targets.
Project work loses to urgent operational demands.
The resulting delay spreads through dependencies: configuration waits for information, testing waits for configuration, and training waits for stable workflows.
How to make internal capacity visible
Treat client participation as scheduled work.
Every major deliverable needs an owner, an effort estimate, a deadline, and clear quality requirements. “Submit inventory data” is insufficient. Specify fields, formats, validation rules, and the person authorized to approve corrections.
Provide templates early and validate a small sample before employees prepare the full dataset.
Most importantly, management must decide which regular duties will be reassigned, postponed, or supported.
Assigning project responsibilities without releasing time creates a schedule built on hope.
Every major deliverable needs an owner, an effort estimate, a deadline, and clear quality requirements. “Submit inventory data” is insufficient. Specify fields, formats, validation rules, and the person authorized to approve corrections.
Provide templates early and validate a small sample before employees prepare the full dataset.
Most importantly, management must decide which regular duties will be reassigned, postponed, or supported.
Assigning project responsibilities without releasing time creates a schedule built on hope.
4. Responsibility Without Authority: When the Lead Can Only Follow Up
A capable employee can coordinate an implementation while lacking the authority to move it forward.
The project lead is expected to obtain information from department heads, reconcile requirements, and secure executive approvals. Yet that person cannot set departmental priorities or resolve disagreements.
Being a subordinate does not prevent someone from leading successfully. The problem is a mandate that carries responsibility without sufficient decision rights or executive backing.
The project lead is expected to obtain information from department heads, reconcile requirements, and secure executive approvals. Yet that person cannot set departmental priorities or resolve disagreements.
Being a subordinate does not prevent someone from leading successfully. The problem is a mandate that carries responsibility without sufficient decision rights or executive backing.
Case 3: U.S. Navy ERP—Risks Identified, Authority Missing
A 2008 U.S. Government Accountability Office audit found that the Navy ERP program was more than two years behind schedule. Among the weaknesses were ineffective mitigation of data conversion and organizational change risks.
The report stated that, according to program officials, the program office:
“does not have the authority to compel the user organizations to execute their part of the mitigation strategy.”
The first user organization experienced significant operational testing problems that required additional time and resources to correct. This was a SAP-based program, not an Odoo implementation, but the documented governance problem is directly relevant to ERP leadership. 5
The management lesson: Identifying a dependency is insufficient when nobody can ensure the responsible department delivers it.
The management lesson: Identifying a dependency is insufficient when nobody can ensure the responsible department delivers it.
How to give the project effective authority
Appoint an executive sponsor who can resolve competing priorities, commit resources, and decide matters beyond the project lead’s mandate.
Authorize the operational lead to make routine decisions within agreed limits. Name process owners who can approve workflows and validate results.
Set response deadlines and an escalation route. A routine decision might have a three-working-day target, for example, with overdue items referred to the sponsor.
Record decisions, owners, and consequences. Repeatedly discussing an unresolved issue should trigger escalation.
Authorize the operational lead to make routine decisions within agreed limits. Name process owners who can approve workflows and validate results.
Set response deadlines and an escalation route. A routine decision might have a three-working-day target, for example, with overdue items referred to the sponsor.
Record decisions, owners, and consequences. Repeatedly discussing an unresolved issue should trigger escalation.
Why These Problems Reinforce One Another
Systems thinking examines how the causes interact.
Ambiguous requirements generate questions. Questions lead to additional requests. Additions increase workload. Overloaded employees respond slowly. Delays create more opportunity for organizational changes, which generate further revisions.
Weak authority allows the cycle to continue.
Critical thinking helps management choose the right intervention by testing explanations.
If data is late, is the cause insufficient time, unclear instructions, poor source records, or uncertainty over who can approve corrections?
If customization is requested, does it address a necessary control, a real operational gap, or a familiar habit from the previous system?
If a department rejects a workflow, is the issue functionality, training, accountability, or loss of decision-making power?
Each explanation calls for a different remedy.
What Senior Managers Should Review Every Week
A useful project review should produce decisions and remove obstacles.
Review area | Question management should ask |
Scope | What changed, and have we approved its consequences? |
Capacity | Do employees have time to deliver their commitments? |
Dependencies | Which unresolved item is holding up critical work? |
Authority | Who must decide, and by when? |
Readiness | Can users complete realistic transactions with validated data? |
Schedule | What evidence supports the current launch date? |
Track trends in overdue inputs, unanswered decisions, reopened requirements, and failed tests. These can reveal deteriorating conditions before a missed milestone makes them obvious.
Require the implementation partner to provide equally transparent reporting on its own deliverables, defects, estimates, and staffing. Accountability belongs on both sides.
Finishing Begins With Leadership
The cases offer different perspectives. G&L illustrates a focused initial release. XLG shows the importance of defining deployment boundaries within organizational complexity. The Navy audit demonstrates how data readiness and limited authority can undermine delivery.
None provides a universal timetable. Together, they point to practical leadership responsibilities: keep the destination clear, allocate real capacity, validate assumptions, and make decisions promptly.
An Odoo implementation partner must deliver competent analysis, configuration, testing support, and honest reporting. Management must provide business ownership and organizational commitment.
Before asking why the project has missed its deadline, ask:
Have we agreed on what “finished” means, given people time to do the work, and empowered someone to keep decisions moving?
The answers may reveal the most effective place to intervene.
XEM, Xcitech Business Consulting
[2]: https://www.odoo.com/blog/customer-reviews-6/gl-systemhaus-2040?utm_source=chatgpt.com "Odoo Success Story: How G&L Boosted Efficiency by 40%"
[3]: https://www.eisenhowerlibrary.gov/eisenhowers/quotes?utm_source=chatgpt.com "Quotes"
[4]: https://www.odoo.com/ar/blog/customer-reviews-6/transforming-a-9-000-employee-company-in-just-six-months-1342?utm_source=chatgpt.com "XLG: Transforming a 9,000-employee company in 6 months"
[5]: https://www.gao.gov/assets/a280055.html?utm_source=chatgpt.com "GAO-08-896, DOD Business Systems Modernization: Important Management Controls Being Implemented on Major Navy Program, but Improvements Needed in Key Areas"