Change Request vs Change Order: What's the Difference and Why It Matters

Every team has their own vocabulary for scope changes. Some call them Change Orders (CO). Some call them Change Requests (CR). Some use both terms — sometimes for the same thing, sometimes for different steps in the process. The terminology isn't always the problem. The process is.

In a Statement of Work (SOW) review, one of the first things I flag is whether the change control section defines its own terms. Not because language is pedantic, but because undefined terms create gaps — and gaps are exactly where scope disputes live.

The Standard Distinction

In most structured delivery frameworks, CR and CO describe two different stages of the same process:

A Change Request (CR) is the ask. It's how someone — the client, the project manager, the delivery team — formally documents that a change to the project scope, timeline, or budget is needed. It says: something needs to be different. Here's what and why. It is not an approval. Work does not start from a CR.

A Change Order (CO) is the authorization. It's the executed document that amends the original Statement of Work. It defines the new scope, the cost impact, the timeline impact, and it carries signatures from authorized parties on both sides. When it's signed, the contract changes. Work can start.

The sequence is: someone submits a CR → the team assesses the impact → a CO is drafted with the agreed scope and cost → both parties sign → work begins.

Treating those two steps as the same thing is where the trouble starts.

But Some Teams Do It Right With Different Labels

Here's where this gets nuanced — and I want to be direct about it, because I've worked alongside organizations that handle this well under a naming convention that looks wrong from the outside.

Some teams use "Change Request" to mean what others call a Change Order. They get everything signed. They document the scope and cost impact. They don't start work until execution is complete. The document is called a CR, but the process is sound.

If that's your organization, the label isn't the issue. The execution is what matters. What I'd still recommend: make sure your Statement of Work defines your terms explicitly. If your SOW says "Change Order" but your team issues "Change Requests," your contract has a gap. A client's attorney will notice. A mediator will notice. Align the language before you're in a room where that misalignment costs you.

The Three Questions That Actually Matter

Regardless of what you call the document, any change to a project scope should pass these three tests before work begins:

1. Is it signed by authorized signatories on both sides? Not a PM. Not a project sponsor. The people named in the SOW as authorized to amend the contract.
2. Is the scope and cost impact documented? Not "TBD." Not "we'll figure it out." The change, what it costs, and how it affects the timeline — in writing, in the document.
3. Was it executed before the work started? Not during. Not after. Before.

If the answer to any of those is no, you don't have an authorized change. You have an undocumented scope commitment — and a dispute waiting to happen.

What Your SOW Should Define

Most SOW change control sections are thin. They say changes require approval in writing, and stop there. A well-drafted clause covers five things:

1. How changes are submitted

Define the method. Is it a form? A formal CR document? An email to a specific inbox from an authorized contact? Vague submission criteria lead to verbal requests that someone on your team feels obligated to honor.

2. Response timeline

How long does your team have to assess a CR and respond with a CO? Seven business days is standard. Without a defined timeline, you're either pressured to turn things around instantly or accused of holding a project hostage while you evaluate.

3. What triggers formal authorization

Any change to scope, timeline, or cost should require a CO. Say it plainly. Don't leave room for a client to argue that a "minor" addition doesn't count.

4. Who can authorize

Name the role or the individual — on both sides. This is one of the most overlooked elements in SOW drafting. Without it, anyone in the client organization with a business card can verbally approve scope, and you'll have a hard time proving they weren't authorized to do so.

5. What happens to work performed without a CO

This is the clause almost no one includes, and it's the most important one when things go sideways. Add language that addresses unauthorized work explicitly — whether it's billed as additional services, absorbed, or stopped pending authorization. The position doesn't matter as much as having one.