Change orders are where fixed-fee deals go to die. Here are three taken apart on the table: what triggered each one, what it cost, and the clause that would have stopped it. Then check your own SOW against the same eight tells.
The autopsy, performed where it should be: before signature, while the clauses can still be rewritten.
A change order is rarely a surprise to the vendor. That is the part buyers get wrong. Most of the change orders I have watched land on steering committee tables were foreseeable at signature, and some were structured at signature. The work was always going to be needed; the only question was whether it would be priced into the deal while you had leverage, or sold to you later when you had none.
The three cases below are drawn from real programs. Two are from the field, anonymized and rounded. One is from the public record of an ERP lawsuit. Each follows the same format: the setup, the trigger, the invoice, and the clause that would have prevented it.
The one idea to hold onto
Every ambiguity in a signed SOW resolves in the vendor's favor. Change-order discipline is not a process you run during the program. It is a set of drafting decisions you make before you sign.
The case files
The setupA fixed-fee deployment. Testing support was written into the original SOW as a separate "guided test services" appendix: described in detail, effectively priced, and deliberately held out of base scope.
The triggerMonths in, the program hit the test phase and needed exactly that support. The appendix was activated through a change order.
The invoiceRoughly $90,000. The change-order reason field said the deliverables were "now in scope as originally outlined" in that appendix. Nothing improper occurred. The foreseeable, essential work of testing had been structured from day one to convert into a paid change later.
The clauseBefore signing, walk every appendix and assumption and ask one question: is this foreseeable work structured to become a change order? Anything essential moves into base scope. Anything genuinely optional gets pre-priced with a fixed cap, so predictable work cannot be sold to you twice.
Verdict: preventable at signature. The tell was visible in the document structure itself: detailed, priced-ready scope sitting outside the base fee.
The setupThe SOW gave the vendor "data conversion." Read closely, the vendor owned only the last mile: loading files the client delivered. Cleansing and remediation stayed with the client, buried in the assumptions section.
The triggerIn practice 10 to 20% of legacy data typically needs business remediation before it will load. The client team discovered this mid-conversion, behind schedule, with the SI's conversion consultants idle and billing.
The invoiceRemediation support sold back on time-and-materials at the moment of maximum desperation, plus the schedule-delay change order when integrated testing surfaced the data issues the client now owned. Two invoices from one assumption.
The clauseDefine conversion ownership end to end: profiling, cleansing rules, mock conversions with exit criteria, load, reconciliation. If the vendor owns loading only, price the remediation support in base scope now, at rate-card prices, and strike any assumption that converts client-owned data work into schedule-delay change orders.
Verdict: the most common change order in ERP, and the most predictable. If your SOW says "client provides clean data," you have already bought this change order. You just have not received the invoice yet.
The setupPublic record. A manufacturer signed a $69M implementation with a major integrator. Fixed fee, which on paper shifts execution risk to the vendor.
The triggerVendors claw fixed-fee risk back two ways: define scope narrowly and bill everything outside it, and pad the bid with contingency. Here the scope definition side did the work, change order by change order.
The invoice51 change orders totaling $23M, taking the program to roughly $94M. Go-live slipped five times over eighteen months. The customer ultimately claimed damages exceeding $172M in litigation.
The clauseThree drafting decisions: define what constitutes a change order precisely, price every change against a rate card negotiated before work begins, and make the SI absorb the cost of its own estimating errors and omissions. A count threshold helps too: past an agreed number of change orders, executive review triggers automatically on both sides.
Verdict: 51 change orders is not 51 surprises. It is one contract structure, invoiced 51 times.
Check your own SOW: the 8 tells
Every one of these is checkable before signature, from the document alone. Tick what is true of the SOW in front of you.
Change order exposure check
What to do with a live one
If a change order is already on your desk, the sequence is short. First, test it against the original SOW yourself before anyone negotiates price: a surprising share of change orders describe work the base scope already covers, once you read the base scope as carefully as the vendor did. Then price it against the rate card, not against a fresh quote. Then ask the only question that reframes the conversation: was this foreseeable at signature, and if so, why is it a change?
On paper the change-control board handles all this. In practice the board approves what the program manager brings it, which is why the review has to happen before the request reaches the agenda.
Where 9Nation fits
I review SOWs and live change orders for buyers: the appendix walk, the assumptions rewrite, and the rate-card structure, done before signature while you still have leverage. The full negotiation guide is free at Negotiating with your System Implementer, and the defense sheet below travels well into a steering committee.
