ERP scope creep: a change request that protects the budget
Use a clear ERP change process to distinguish defects, clarification, new requirements, and buyer dependencies before approving extra cost or delay.
Control ERP scope changes by comparing each request with the approved requirement and acceptance criteria. Decide whether it is a defect, clarification, new requirement, or changed assumption, then document the cost, schedule effect, and approval. A change process should make tradeoffs visible without blocking necessary learning during implementation.
Establish a usable baseline
Keep the signed scope, workflow requirements, design decisions, assumptions, exclusions, and acceptance tests in one versioned record. The baseline must be detailed enough to answer whether a request changes the agreed work. “Standard implementation” is not a sufficient reference if the parties have different ideas about reports, interfaces, migration, or training.
Give business owners a way to understand the baseline. A technical specification that nobody in operations can interpret may satisfy a filing requirement while failing to prevent disputes. Use examples and expected outcomes. Where a design decision remains open, record its owner and deadline. An unresolved decision should not be quietly assumed in whichever direction makes the initial price look lowest.
Classify the request before pricing it
| Request type | Question to resolve | Useful evidence |
|---|---|---|
| Defect | Does agreed behavior fail? | Acceptance test and actual result |
| Clarification | Is the baseline ambiguous? | Requirement and decision history |
| New requirement | Is a new outcome requested? | Business rationale and owner |
| Changed assumption | Did an agreed condition change? | Original assumption and new fact |
| Buyer delay | Was a dependency missed? | Responsibility and schedule record |
The classification can have contractual consequences, so do not assume a label automatically determines who pays. Have procurement or counsel review disputed responsibilities when necessary. The operational goal is to understand the request; the commercial documents determine how the resulting work is treated. Keep the technical diagnosis separate from an unsupported legal conclusion.
Require a decision-ready change record
A change record should contain the trigger, requested outcome, alternatives, affected workflows, deliverables, cost basis, schedule effect, dependencies, test, and approving authority. Ask whether a configuration change, process adjustment, or phased delivery could meet the need with less disruption. Include the ongoing maintenance consequences of custom work, not only the initial development estimate.
For an illustrative request, a new approval branch may require 12 hours of configuration, eight hours of testing, and four hours of training preparation. At a fictional blended $150 hourly rate, 24 hours would be $3,600. That arithmetic does not prove the estimate is reasonable. The team still needs to understand the work, roles, assumptions, and whether the requested behavior was already included.
Link approval to authority and funding
Specify who can authorize additional spending and who can accept an operational tradeoff. A process owner may approve the design while a budget owner approves the fee. The partner should know both requirements. Avoid informal instructions that allow well-intentioned employees to expand scope without understanding the cost. Equally, give the team a timely path to approve urgent, justified work.
Maintain a change log showing proposed, approved, rejected, deferred, and completed requests. Update the forecast to complete and milestone plan when a change is approved. A separate spreadsheet of changes that never reaches the project budget creates a false picture of affordability. Track the cumulative effect, because several small changes can consume the same capacity as one large workstream.
Learn from the pattern of changes
Review why requests arise. Repeated changes in one process may reveal that requirements were poorly understood, the wrong owner attended design sessions, or the proposed product fit depends on extensive customization. Respond to the cause rather than treating every request as an isolated transaction. A short design review may be more useful than continuing to approve incremental work.
Before launch, confirm that approved changes are tested, documented, and reflected in training and support arrangements. Deferred changes need an agreed temporary process and owner. Rejected requests should have a reason so they do not reappear as unexplained defects. A disciplined change process preserves the buyer's ability to make conscious decisions about scope while giving the delivery team a stable and reviewable basis for work.
Approval worksheet
Before approving a material change, ask the team to show the revised end-to-end workflow and its test impact. A small field or report request can affect interfaces, permissions, migration, training, and support. Require those effects to be considered in the estimate. Where the team proposes a quicker workaround, record how it will be controlled and whether it is temporary or permanent.
At each budget review, reconcile approved changes with purchase orders, delivery tasks, and the forecast. Remove rejected work from the plan and keep deferred work visible with an owner. Review whether the contingency still matches the remaining uncertainty. After the change is delivered, verify acceptance and update documentation before closing the record. This avoids a common administrative gap in which the fee is approved and invoiced but the operating team never receives the new procedure, test evidence, or maintenance responsibility.
FAQ
Is every request after design approval extra scope?
No. It may expose a defect or an ambiguity in agreed work. Compare it with the baseline and relevant contract terms. Do not accept or reject a fee solely because of when the request appeared.
Should we prohibit all customizations?
That can be too crude. Evaluate the requirement, alternatives, initial cost, testing, ownership, and long-term maintenance. Approve custom work only with a defensible purpose and a supportable design.
Can contingency pay for changes automatically?
A reserve does not replace approval. Apply the organization's authority rules and record the scope and forecast impact. Unused reserve should remain visible rather than becoming an invitation to add work.
Sources
- Microsoft Business Central pricing — consult current product and partner information; the hourly example is fictional and unrelated to Microsoft rates.
Continue the workbook
- ERP project risk register: turn concerns into actions
- ERP exit planning: test the export before you need it
- ERP go-live support: budget for stabilization and ownership
Use the ERP total cost calculator for your own scenario, the quote readiness checklist to track evidence, and the cost structure comparison to review purchasing models.
