Why Change Orders
Fix the Wrong Problem

Here's a pattern worth examining: the agency owner who did everything right on change orders and still had margin problems.

They implemented the process. They trained the team. New scope gets flagged, documented, and priced before work begins. Clients sign off. Nobody builds anything without a paper trail.

And yet, at year-end, the margin still doesn't match what the numbers should say. Projects still close with unexplained gaps. The PM team is exhausted. Something is still broken.

The problem isn't the change order process. The problem is that change orders are solving the wrong problem.

What Change Orders Actually Do

A change order documents a scope change after it's been identified. It creates a paper trail for additional work that someone — a client, a stakeholder, a PM — has already agreed to informally. It converts a verbal or Slack-based commitment into something billable.

That's genuinely useful. It's also entirely reactive.

By the time a change order is in play, several things have already happened: someone recognized that new work was being requested, someone decided to formalize it rather than absorb it, and the client has already mentally committed to the work happening. The change order isn't preventing scope drift — it's documenting it after the drift has occurred.

This isn't a criticism of change orders. It's a description of their job. They're a downstream instrument for a problem that lives upstream.

The Problem They Can't Solve

Change orders require a baseline to be meaningful. They only work when there's a clearly defined original scope to compare against — a document specific enough that the new request is obviously outside it.

This is where most agencies' change order processes quietly break down.

If the original SOW says "design the website," then "add a contact form" might be inside scope or outside scope depending on who you ask. The change order conversation becomes a negotiation about what was originally meant, not a clear documentation of what changed. Both parties have reasonable interpretations. The friction is high. Often the path of least resistance is to absorb the change and avoid the argument.

The change order process doesn't fail because teams don't use it. It fails because the thing it's supposed to protect — a precisely defined original scope — doesn't exist. You cannot document a deviation from a baseline that was never established clearly.

The Scope of "Can We Just Add One More Thing"

Think about the requests that actually generate scope disputes in your agency. They rarely start as "I'd like to formally request a change to the project scope." They start as:

• "Can we just add one more thing?"
• "While we're at it, could we also...?"
• "I assumed that included..."
• "We talked about this on the call."

These aren't requests for change orders. They're attempts to reinterpret a scope that was never specific enough to prevent reinterpretation. The client isn't being difficult — they're filling in a gap that the original brief left open. They genuinely believe they're asking for what was agreed.

A change order process catches some of these, when a PM has the presence of mind to flag them and the social confidence to formalize them. It misses the ones that seem small, the ones that come from important clients, the ones that arrive in the last week of a project when everyone wants to finish, and the ones that get absorbed by team members who don't know the change order process exists.

It will always miss these, because it depends on individual judgment under social pressure. That's an unstable foundation for margin protection.

Where the Real Fix Lives

The fix is upstream, in the original scope definition.

When deliverables are defined as specific outputs — not categories of work, not activities, not intentions — scope changes become visible before anyone has to decide whether to flag them.

"Design the website" is a category. It can absorb almost anything.

"Design five pages, each with defined sections, with copy provided by client by kickoff, with two rounds of revisions included, with any additional pages or revision rounds billed at [rate]" is a deliverable definition. It can absorb almost nothing without making the addition visible.

The test is simple: can a reasonable person read your SOW and know immediately whether a given request is included or not? If the answer requires judgment — if it depends on what you meant, what the client thought you meant, what was discussed on a call — the SOW is too vague to support a change order process.

Scope precision doesn't make change orders disappear. It makes them shorter. When the original scope is unambiguous, the change order conversation is "this falls outside section 3.2, here's the rate" rather than "well, we thought this was included, and here's what we understood the project to mean, and..."

The Right Role for Change Orders

Change orders aren't the problem. Treating them as the primary scope management tool is.

At their best, change orders are the last line of defense in a system where the first three lines of defense — structured intake, precise scope definition, documented assumptions — have already done most of the work. They handle the edge cases, the genuine changes that weren't foreseeable at kickoff, the client decisions that legitimately evolved.

At their worst, they're the only line of defense in a system where scope was never defined well enough to make deviations visible. In that system, they work sometimes — when the PM catches the change, has the courage to raise it, the client isn't too important to push back on, and the timeline has enough room to wait for sign-off. They fail systematically in every other case.

Most agencies are using change orders in the second way and wondering why the first way isn't working.

The answer isn't a better change order template or more aggressive enforcement. It's building the upstream system that makes change orders a formality rather than a confrontation.

What Actually Changes the Math

Agencies that have solved the margin problem at scale share a pattern: they invested in scope clarity before pricing, not change order rigor after delivery.

The shift looks like this: instead of asking "how do we ensure clients sign change orders for scope additions," they ask "how do we define scope precisely enough that additions are self-evident?" The first question builds a better catch. The second question builds a smaller net.

When scope is precise enough that a change is obviously visible, the change order conversation is brief and rarely contested. Clients who understood the original agreement understand the change. The friction dissolves, not because the culture changed but because the document is doing the work that culture was never designed to do.