Change Request Management (CRM, sometimes CR Management to avoid confusion with customer relationship management) is the structured contractual process by which scope changes to an existing IT services agreement are proposed, costed, approved, and executed. It is the most common path through which an outsourcing contract's run-rate drifts away from its original commercial baseline.
Why it exists.
Every multi-year IT services agreement signed today will need to change before it ends. Volumes shift. Regulation moves. New systems land. Acquisitions happen. The original SOW captures the world as the buyer understood it on the day of signature; reality begins diverging from that document the day after.
The contract has to handle that. The mechanism it uses is the Change Request — a defined, costed, mutually-agreed amendment to scope or pricing. Without one, every divergence is renegotiated from scratch, which is slow and expensive. With one that is poorly designed, every divergence becomes a small revenue uplift for the vendor that nobody in finance is reconciling against the original business case.
What a well-designed CR process looks like.
- Defined trigger thresholds. What constitutes a change requiring a CR (e.g. >5% volume variation, new service, modified SLA) versus what falls within elastic scope.
- Standard pricing logic. The CR is priced using the rate card and pricing methodology already in the master contract — not as a free-form estimate.
- Required impact assessment. Every CR specifies impact on price, on SLAs, on dependencies, on the run-rate going forward.
- Time-boxed approval. Both parties commit to respond within a defined window, typically 5 to 15 business days depending on materiality.
- Audit trail. Every CR is numbered, signed, dated, and reconcilable against invoicing.
- Run-rate visibility. The cumulative effect of all approved CRs on the annual run-rate is reported at managerial governance, not buried in line-item invoicing.
The two failure modes.
Over-rigid: every minor adjustment requires a formal CR. Result: operational friction, slower service evolution, vendor frustration. Common in contracts where governance was designed by lawyers without operational input.
Under-rigid: CRs flow through informal channels, get approved by service owners without finance visibility, and accumulate. Original SOW for €X. Two years later, run-rate is 1.5× the original, distributed across 47 small CRs nobody has consolidated. This is the more expensive failure.
FAQ.
Who approves change requests?
Operationally, service owners on both sides; commercially, the vendor management or procurement function on the buyer side. Material CRs (typically >€100k or affecting strategic SLAs) should require sign-off at the managerial governance forum.
Should change requests be tracked centrally?
Yes. The cumulative run-rate impact of CRs is visible only at the portfolio level. Without central tracking, individual CRs look reasonable while the aggregate quietly inflates the contract.
What is the typical CR uplift over a contract life?
Across the engagements we review, multi-year IT outsourcing contracts typically end with a run-rate 15–35% above the original SOW. The majority of that uplift comes through CRs rather than through formal renegotiation.
