How to Manage Change During an ERP Implementation

Project Management

Controlling change during an ERP implementation comes down to three habits: knowing your scope of work and design document well enough to recognize the moment something shifts away from them, documenting every change as it happens instead of letting it live in someone's memory, and communicating that change to the key stakeholders who need to sign off on any resulting cost or schedule impact. Skip any one of those three, and small changes quietly turn into scope creep, budget overruns, and a project timeline nobody can defend. Here's how each piece actually works.

60 Seconds on Controlling Change

Featured: Penny Tingle at Business Consulting Leader.

The 3 Pillars of ERP Change Control

1

Know Your Baseline

Your scope of work and design document are the reference point for every decision. You can't recognize a change until you know exactly what was originally agreed to.

2

Document Every Change

Every deviation from the original scope gets written down as it happens, not reconstructed later from memory once someone asks why the budget moved.

3

Communicate the Impact

Key stakeholders hear about the change, and the job cost or schedule impact it justifies, before it becomes a surprise at the next status meeting.

Why This Matters

Change itself isn't the problem. Almost every ERP implementation shifts somewhat from its original scope as teams learn more about the current state and the future state they're building toward. What actually causes damage is change that goes undocumented and uncommunicated, because that's how a reasonable adjustment turns into unexplained scope creep, a budget nobody can account for, or a stakeholder who feels blindsided at go-live. Strong change control is really a communication discipline built on top of a clear design document, which is exactly why we treat it as part of solution design and project kick-off rather than something bolted on afterward.

Signs Your Change Management Has a Gap

1
Changes get agreed to verbally in meetings and never make it into a written record
2
Stakeholders are surprised by cost or timeline shifts they never explicitly approved
3
No one can point to the original scope of work when a disagreement comes up
4
"Small" requests keep getting approved without anyone tracking their cumulative effect
5
The project timeline has slipped more than once and no one can explain exactly why

Related Reading

Frequently Asked Questions

It's the discipline of tracking any deviation from the original scope of work and design document, and making sure the cost or schedule impact of that deviation is documented and communicated before it's acted on.
By recording what changed against the original design document, why it changed, and what it does to cost or schedule, ideally at the moment it's raised rather than reconstructed after the fact.
The stakeholders who own the budget and the timeline, at minimum. If a change affects job cost or the schedule, whoever's accountable for those numbers needs to see it before it's approved, not after.
It tends to resurface later as an unexplained cost overrun or a missed deadline, with no record to justify why, which erodes trust between the client and the implementation team.
It's built into how we run solution design and project kick-off from the start, rather than sold as a separate add-on. The alternative, an undocumented project, almost always costs more later.

Keep Every Change on the Record

A clear scope and design document from day one is what makes change management possible in the first place.

Penny Tingle

Penny is an Acumatica consultant with more than two decades of industry experience. Over that time she has developed a distinctive combination of management consulting and corporate accounting expertise, which she brings to helping clients get the most out of their systems.

https://www.linkedin.com/in/pennytingle-34471/
Next
Next

How BCL Partners With VARs Without Stepping on Their Brand