Implementation services are where software companies discover the difference between a signed deal and a profitable one. The original statement of work is usually estimated carefully, reviewed by delivery and priced with a margin everyone accepts. What happens next is less controlled: a dozen requests arrive over the project, some clearly out of scope, some arguably within it, most agreed in a status call and documented, if at all, in a meeting note.
By the midpoint, the project is running over estimate, the vendor believes the overrun is customer-driven change and the customer believes it was always part of the deal. Both are working from different mental baselines. The argument that follows is expensive, damages a relationship that was supposed to lead to renewal, and is almost always avoidable.
What prevents it is unglamorous: a named scope baseline, a change order form that captures effort by role rather than a total, explicit approval authority on both sides, and a rule that work does not start before authorization. None of it is difficult. All of it has to be in place before the first request arrives, because introducing change control midway through a contested project is read as a defensive manoeuvre.
The six fields a change order needs
Change order templates vary widely in quality. The strong ones capture six things, and the weak ones typically capture two, a description and a price.
- Baseline reference, the exact version of the statement of work and prior change orders that this change modifies, so the delta is unambiguous.
- Scope delta, what is added, removed or altered, written as a difference rather than as a restatement of the whole deliverable.
- Effort and price, hours by role and resulting price, with the rate card version referenced, rather than a lump sum with no visible basis.
- Schedule and dependency impact, the effect on milestones, plus any new customer dependency the change creates, dated.
- Acceptance impact, whether and how acceptance criteria change, stated explicitly even when the answer is that they do not.
- Approval and authority, named approvers on both sides with the threshold under which they are acting, and the effective date of the change.
The baseline reference is the field most often missing and the one that decides disputes. A change order that says it modifies the statement of work dated a particular day, revision three, cannot be argued with on that point. One that refers to the project generally invites exactly the argument it was supposed to close.
The largest single source of unrecoverable services cost is work performed on a verbal go-ahead that procurement later declines to approve. A one-page written authorization capping hours, signed by someone with stated authority, takes an hour to obtain and protects both parties.
Controls that keep change manageable
Five controls address the failures that recur across implementation programmes, whatever the product or the delivery methodology.
- Version the baseline on every change. Each approved change order increments the baseline version. The current scope is then always identifiable as a single reference rather than as a document plus an unknown number of amendments.
- State approval authority in the SOW. Name the individuals and thresholds on both sides at the outset. Asymmetric authority, where the vendor can commit and the customer cannot, causes more disputes than pricing disagreements.
- Log requests, not just approved changes. Track every request, including those declined or absorbed. The declined log is what demonstrates that the vendor has been reasonable, and it is also the best input to the next estimate.
- Reconcile change value to project margin monthly. Compare cumulative approved change value and delivered effort against the original estimate. Programmes that review this monthly can correct; those that review it at closeout can only explain.
- Capture the fields finance needs. Itemized pricing, distinctness of the added services and standalone pricing basis should be recorded at signature, so revenue treatment is determined from the record rather than reconstructed.
A five-step path to working change control
Step 1, Fix the template
Rebuild the change order form around the six fields. This is a half-day exercise and it is the intervention with the highest return, because most change disputes trace to a missing field rather than to a missing process.
Step 2, Establish baseline versioning
Decide how the baseline is identified and incremented, and where the current version is recorded. A version number on the contract record is sufficient; the requirement is that one place holds the answer.
Step 3, Write authority into the statement of work
Add named approvers and thresholds for both parties to the standard SOW template. Customers rarely resist this, because it protects them from unauthorized commitments as much as it protects the vendor.
Step 4, Instrument the request log
Capture requests at the point they arrive, with their status, so the picture of pending change is visible to delivery and commercial teams at the same time rather than sequentially.
Step 5, Review margin against change monthly
Put cumulative change value and effort variance into the monthly project review. The purpose is not reporting; it is to surface the programme that needs a commercial conversation while there is still time to have it constructively.
See change control on a live programme
Walk through baseline versioning, change order approval and margin reconciliation against real statements of work.
Where change orders collide with the contract stack
A change order sits at the bottom of a document stack that usually includes a master agreement, an order form, a statement of work and any prior changes, and the conflicts between those layers surface exactly when a change is contested. A change order that alters a payment term, a liability cap or an acceptance regime may or may not override the layer above it, depending on precedence language nobody consulted. The analysis in when the order form and the MSA disagree applies directly, and the practical protection is to state in the change order template that it modifies scope, schedule and price only, with all other terms unaffected. That single sentence removes a whole class of argument, and it is also the discipline that keeps deal desk from having to arbitrate, as covered in the SaaS deal desk bottlenecks guide.
Change order maturity and what each level prevents
The table below describes the levels of change control seen in practice and the failure each level removes.
| Level | Practice | Prevents | Remaining exposure |
|---|---|---|---|
| Verbal agreement | Changes agreed in status calls | Nothing | Unrecoverable work; disputed scope |
| Written description and price | Change order with scope and total | Denial that a change occurred | Baseline and pricing basis both contestable |
| Baseline referenced | Change order names SOW version | Argument about what changed from what | Pricing basis still opaque |
| Itemized by role | Hours by role against rate card | Unauditable pricing disputes | Acceptance criteria may lag scope |
| Full six fields with authority | All six captured, approvals named | Most implementation disputes | Requires discipline on no-work-before-authorization |
Change control on services work is a template problem before it is a process problem. Most disputes reduce to a missing baseline reference, an unitemized price or an approval given by someone without authority to give it. Fixing the form and writing authority into the statement of work costs a day of effort and removes the majority of the exposure, which is a better return than any amount of downstream negotiation.
For related guidance, see The IT leader’s guide to SaaS vendor contract sprawl, Auto-renewal clause risk in enterprise SaaS contracts and Benchmarking clauses in outsourcing contracts.
