ERP Scope Creep: When Every User Request Gets a Yes

Recently Ben Van Aken spoke with a company, not a client, that had upgraded from Dynamics NAV to Business Central. On paper, it was a modernisation. In the warehouse, it went the other way: the company was shipping fewer packages a day, with more people on the floor than before.

From what they told him, the new software was not the main cause. User requests had got out of control. Requests were accepted one by one, and nobody added up what they cost on the warehouse floor.

That is what ERP scope creep usually looks like. Not one big wrong decision, but a long list of small yeses.

Why every request sounds reasonable

During an ERP project, every department gets a chance to ask for what it always wanted. Sales wants an extra check before an order is released. Customer service wants a few more fields on the order. Finance wants an approval step. Each request makes sense to the person asking, and each one is small.

The problem is that nobody looks at the total. Every extra field has to be filled in by someone. Every extra check is a moment where an order waits. Every approval step is a queue. In a warehouse, those small delays turn directly into fewer packages out of the door and more people needed to ship the same volume.

Two things make this worse in ERP projects:

1. The people asking are not the people paying the price. A request from the office often lands as extra work in the warehouse, on the road or in customer service.
2. The implementation partner builds what is asked. That is their job. Deciding what should be asked stays with the company.

Start with the KPIs, not the wish list

The best protection against scope creep is to agree, before the project starts, which business results the ERP has to deliver. For a distribution company, that could be:

• packages or order lines shipped per picker per day
• order lead time from entry to shipment
• share of orders delivered complete and on time
• time spent on manual corrections in customer service

Measure them before the project starts. Then every change request gets one simple question: which of these numbers does it improve, and what does it cost in the others?

A request that does not improve a KPI is not automatically wrong. But it should be a conscious decision, made by someone who sees the whole process, not a default yes.

Put one gatekeeper in front of every request

In most companies, nobody is formally responsible for saying no. Key users represent their own department. The partner consultant represents the configuration. Management is too far away from the detail.

That gap is where a freelance ERP/CRM project lead earns their fee. Ben's role in a project is exactly that: an outside gatekeeper who questions every step, keeps the focus on the agreed KPIs and holds everyone accountable, including the partner and the internal teams.

In practice, that means:

• Every request is written down, with who asked, why, and which process it touches.
• Every request is checked against the process, end to end. What happens in the warehouse when this field becomes mandatory in the office?
• Every request gets an owner and a decision: now, later, or not at all.
• Phase two is a real place. Good ideas that do not serve the go-live goals are parked there, not quietly built in.

A simple change request template

You do not need a heavy tool. One page per request is enough:

1. What is the request, in one sentence?
2. Who asked for it, and which department does the extra work?
3. Which KPI does it improve, and by how much do you expect?
4. What does it add per order, per day: clicks, fields, checks, waiting time?
5. What happens if we do not do it?
6. Decision, decided by, date.

Question 4 is the one most projects skip. It is also the one that would have shown the warehouse problem above before go-live, not after.

Check the result after go-live

Scope creep does not stop at go-live. Requests keep coming in hypercare, and they are often handled even faster because users are under pressure. Keep the same rules after go-live, and compare the KPIs with the numbers you measured before the project. If shipping per picker goes down, look at what was added to the process before you look for more staff.

If the numbers already went the wrong way, the fix is usually not a new system. It is a review of every step that was added, with the people who do the work, and the courage to remove what does not earn its place.

A short checklist

1. Agree three to five business KPIs before the project starts.
2. Measure them before go-live.
3. Log every change request, with who asked and who does the extra work.
4. Ask what each request costs per order, not only in project days.
5. Name one person who decides, independent of the departments asking.
6. Park good ideas in phase two instead of building them in.
7. Keep the same rules during hypercare.
8. Compare the KPIs after go-live and remove steps that do not pay off.

The bottom line

ERP scope creep is rarely a technology problem. It is a governance problem: many reasonable requests, and nobody who weighs them against the business result. Put the KPIs first, put one gatekeeper in front of every request, and the system stays as lean as the operation needs it to be.