Scope creep is the continuous, unauthorized, or undocumented growth of a project's requirements after the initial plans have been established. In the world of ERP implementation, it is the number one reason projects blow past their budgets and go-live dates.
As we discussed in Change Management Isn't a Memo, users naturally resist learning a new system. When faced with Odoo, their instinct is often to say, "Can we make Odoo look and behave exactly like our old system?" This is the genesis of scope creep.
"Can we just..." are the three most dangerous words in an ERP project.
The Anatomy of Creep
Scope creep rarely happens via a massive, malicious demand. It happens via a death by a thousand papercuts. A warehouse manager asks the developer to add a custom column to a report. The HR manager asks for a "small tweak" to the leave approval workflow. The developer, wanting to be helpful, says "Sure, that takes five minutes."
But that five-minute UI change requires updating the database schema, modifying access rights, rewriting automated tests, and updating training manuals. Five minutes of coding creates five hours of technical debt.
Real Bangladesh Examples
The "I want to see everything" MD
In a textile implementation, the Managing Director requested a custom dashboard. Initially scoped as 5 key metrics. During weekly demos, the MD kept saying, "This is great, but can we just add a chart for daily yarn waste? And another for worker absenteeism?" After 4 weeks, the dashboard had 32 custom charts, loading the system down so heavily it caused timeouts. The project was delayed by 3 weeks just to optimize a dashboard that was never in the original scope.
Rebuilding Excel in Odoo
An accounting manager insisted that the Odoo invoice printout must look exactly pixel-for-pixel like their legacy Excel template, right down to the specific border weights and merged cells. Native Odoo reports are HTML/PDF based. The partner spent 40 billable hours hacking QWeb reports just to satisfy an aesthetic preference that added zero business value.
The Three Defenses
To protect your Implementation Roadmap, you must build three walls of defense:
- A bulletproof Requirements Document: If it is not in the BRD, it is not in scope. Period.
- A definitive Project Charter: A charter doesn't just say what you will do; it explicitly lists what you will not do (e.g., "Phase 1 will NOT include HR payroll integration").
- A strict Change Request (CR) Process: You do not say "No" to scope creep. You say, "Yes, please fill out this Change Request form."
Handling Change Requests
When a user asks for a new feature, the Project Manager must pause the work and initiate the CR process:
- What is the business justification for this change?
- How many additional hours will this take to build, test, and deploy?
- What is the cost impact?
- Does this push back the Go-Live date?
Once the Steering Committee sees that a "tiny button" costs BDT 25,000 and delays go-live by 3 days, 90% of scope creep miraculously disappears. The remaining 10% are usually valid, critical changes that are officially approved and budgeted for.
Frequently asked questions
What is scope creep in an ERP project?
Scope creep refers to the continuous, unapproved addition of new features, reports, or requirements to an ERP project after the initial contract has been signed and development has begun. It is the primary cause of budget overruns and delayed go-lives.
How do you prevent scope creep?
Preventing scope creep requires a highly detailed Business Requirements Document (BRD) upfront, a signed Project Charter that explicitly lists what is OUT of scope, and a strict Change Request (CR) process where any new feature must be estimated for cost and time before approval by the steering committee.