ERP Change Requests: Why the First SI Change Request Sets the Tone for Your Entire Program

There’s a moment in every transformation program where vendor governance gets its first real commercial test. You probably won’t recognize it when it happens. It isn’t when a milestone slips, or when the steering committee starts hearing about what happened last month rather than what’s forecast for next month. It’s earlier.

It’s typically the first material change order. The one that arrives looking routine, gets reviewed by someone trying to clear their inbox, and gets approved without anyone noticing that the precedent for every subsequent CR has just been set.

By the time the tenth change request lands, the rates are normalized, the SI has had nine CRs to learn exactly how hard the client pushes back, and the precedent is locked in. Whatever happens after that is mostly arithmetic. The program wasn’t lost at CR #10. It was lost at CR #1.

Why the First ERP Change Request Creates Long-Term Commercial Risk

The submission sitting in your approver queue looks like a request. It isn’t. It’s a probe, and your SI is testing three things in a specific order:

• Will you read the CR against the SOW?
• Will you route it through Integrated Change Control?
• Will you approve it even if both answers are no?

The dollar figure is a decoy. What the SI is actually pricing is how much attention you’re paying.

Across UpperEdge’s implementation database, which covers about $70B in program costs and hundreds of millions of hours of SI staffing models, the pattern doesn’t vary much by industry or platform. On poorly governed programs, base SOW leakage runs somewhere between 12 and 18 percent of total contract value. That’s $6M to $9M on a $50M engagement. On a $200M program, it’s $24M to $36M, all of it for scope the client believed was already paid for.

We’ve also seen this from the contingency-planning side: 10 to 15 percent scope contingency is the planning norm, and where a given program lands inside that range depends almost entirely on how actively the client is pushing back against the inflow. The SOW doesn’t change much between a well-governed and a poorly-governed program. What changes is the first CR response.

To put it more bluntly: SIs have spent a decade refining their contracts so hard-to-quantify risks are buried in plain sight. The change order isn’t where the SI is being dishonest. It’s where the SI collects on the contract you signed without reading as carefully as you should have.

Why Negotiating ERP Change Order Pricing Misses the Real Risk

Here’s how clients typically fail the test. The CR arrives at $500K. Procurement grinds the SI down to $430K over two weeks of emails. The CFO reports a 14 percent savings to the audit committee. Everyone goes home feeling like they did their job. But the SI submitted the CR at $500K expecting to settle around $430K. The number was never a cost estimate. It was a negotiating posture, and the posture worked exactly as designed.

The real test was whether anyone was going to ask these four questions before the number got approved:

Does the ERP Change Request Reference a Specific SOW Clause?

This does not mean a general reference to “Section 4, Scope.” It means a clause. If the SI can’t point to the language they’re claiming the CR amends, then the work isn’t a change to scope at all. It’s scope the SOW never excluded, which means the client is paying twice for it, once in the base fee and once in the CR.

It’s a pattern I’ve called paying for what you already funded, and it’s the single most common commercial failure I see on mid-life ERP programs. It almost always starts at CR #1.

Is the SI Using a Documented SOW Assumption or Expanding Scope?

Every fixed-price SOW has an assumption log somewhere in the back. When a documented assumption fails, the SI has earned a CR. But when the SI invokes an assumption that was never documented, they’re asserting a right to scope that was never granted. That distinction sounds legalistic until you watch it play out. One version is a valid commercial event. The other is a margin-protection exercise wearing the same clothes.

Does Project Performance Data Actually Support the Change Request?

If the last four status reports have marked the workstream green and the CR now claims the same workstream needs significant unplanned effort, one of those artifacts is wrong. Maybe the status reports were covering. Maybe the CR is inflated. Possibly both. There’s no fourth option, and someone at the steering committee is owed a straight answer about which it is.

Did the Change Request Follow Formal Integrated Change Control?

A CR approved outside formal change control doesn’t create a precedent the program can govern against. It creates one the SI can exploit, because the next CR will point to the first as the way these things get done here.

None of those four questions are about price. If the CR can’t answer all four, the discount is irrelevant.

Who Owns ERP Change Order Governance Across the Program

When a first material CR lands, the governance work becomes about making sure those four questions get asked, in writing, before the commercial conversation starts. This may look different depending on your role in the program:

• Refuse approval until the SI produces the SOW clause citation. Put it in writing and copy Legal. When the SI pushes back and says the clause is “implied,” which they will, remember that “implied” isn’t enforceable. Documented is. If the clause can’t be produced, the commercial treatment isn’t a CR. It’s a contract amendment, and the negotiation should start there.
• Pull the assumption log back out of contracting. Check whether the assumption the SI is invoking actually appears in it. If it doesn’t, this stopped being a CR conversation the moment the SI filed it. It became a Legal conversation, and the sooner it’s treated that way, the less it costs.
• Procurement and sourcing. Benchmark the rates and effort inside the CR against the original staffing model. If the SI’s unit rates have drifted meaningfully, or the seniority mix has shifted materially, what you’re looking at isn’t a change request. It’s a repricing wearing a CR’s clothes, and repricing gets handled differently.
• PMO lead. Confirm Integrated Change Control routing. Log the CR against whatever precedent history exists. Open a standing agenda item at the steering committee for CR precedent review. If the PMO is uncomfortable with that level of visibility, the discomfort is itself telling you something about where governance has quietly softened.
• Executive sponsor. Ask the SI engagement partner on the record: how many additional CRs does the SI currently anticipate through go-live, and what’s the combined commercial exposure? The number matters. The way the SI answers, with a figure, a range, a hedge, or a redirect, matters more.

What the SI’s Response Reveals About ERP Program Risk

Watch what happens when the SI is pressed on these four questions. The response itself is more revealing than the original submission. Call this the Mirror Test: what the SI reflects back tells you whether they’re managing the engagement or investing in the outcome.

An SI that comes back with a revised CR and a mea culpa is still managing the relationship. An SI may come back and say the assumption was missed, the design team lacked coverage during a critical window, and the client still needs to resolve a business-process decision before the scope can be delivered.

That’s an SI investing in an outcome. Program failures almost always run both ways. Slow client decisions. Business resources that weren’t staffed. Requirements that shifted after design was locked. A vendor naming those things alongside their own shortfalls isn’t deflecting. They’re telling you the truth about the engagement, and the truth is always two-sided.

If the SI only names the client, they’re protecting the engagement. If they only accept blame, they’re managing the relationship. If they name both, you’ve got something to work with, and the CR is no longer just a CR. It’s the beginning of a recovery signal you can actually trust.

The ERP Change Order Submission Test: 4 Questions Before Approval

If there’s one thing worth taking from this: stop calling it a change order. The thing in your queue isn’t a change order. It’s a submission test. The SI is submitting a proposal, and the client is being tested on whether the proposal gets read, routed, and responded to like a governed event, or whether it gets approved because someone wanted their inbox back.

The test has a scorecard. Clause citation. Assumption delta. Work Performance Data alignment. Integrated Change Control routing. Four items, pass/fail. No price negotiation until all four are passed.

What the SI learns about how the client treats CR #1 will price every subsequent CR. That’s not a sales tactic. It’s a rational response to information. The SI will assign people, set rates, and structure submissions for the remainder of the engagement based on the answer it gets to a single question on the first CR: does this client read?

Run the scorecard. The second CR, when it comes, will be a different document than the first.

If you have a change order awaiting approval, apply the submission test before signing off, not after. UpperEdge’s Project Execution Advisory Services help clients enforce this discipline when it matters most and have recovered tens of millions in commercial leverage on programs already deep into execution. Learn how.