The Change Order Nobody Wants to Write (and Why It Protects You)

Sooner or later, every project changes in the middle. A supplier alters a specification, a regulator moves a requirement, or the person who commissioned the work realizes they need something different. The change itself is rarely the problem. The problem is handling it with a phone call and a “don’t worry, we’ll sort it out later”, because that is how budgets and relationships get damaged.

A change order is the written, approved record of a change to what was agreed. Nobody enjoys writing one, but it is the cheapest protection a project has.

What a change order is, and when to ask for one

A change order is a formal document that changes the agreed scope, cost or schedule, and states who authorized it. The wording differs by industry (variation order, change request, contract amendment), but the idea is the same: the original agreement stays readable, and every change to it is a separate, signed step.

Ask for one when a change touches anything you committed to: the specification, the deliverables, the budget or the dates. In US federal contracting, for instance, a change order is a written change the government’s contracting officer can issue within the scope of the contract, and the contractor must continue performance of the contract as changed. The lesson for the rest of us is that continuing to work and settling the paperwork are two different steps, and the second one should not be skipped just because the first is already running.

A simple test: if the change would surprise someone reading the original agreement, it needs a change order.

What it has to say

The APM, the UK professional body for project management, describes the evaluation of a change as a look at its effect on scope, quality, time, resources, cost, risks and stakeholders, plus what happens if you do not make the change at all. That last item is the one people forget. Put into a document, it comes to five things:

1. What changed, in one or two sentences, compared with the original agreement.
2. Why it changed, and who or what triggered it.
3. The cost effect, including the cost of doing nothing.
4. The time effect, with the new dates.
5. Who approves it, by name and role, and the date they did.

If any of the five is missing, the document is a note, not a change order. And approval has to come from someone with the authority to give it. The UK government’s project delivery guidance is explicit that changes beyond a person’s authority are escalated, not absorbed.

Keeping the conversation factual

The hardest case is when a partner caused the change. The temptation is to open with blame, but blame changes nothing on paper: the cost and the schedule are the same either way.

A framing that works: the specification changed, here is what it does to cost and time, here is what I need signed. That keeps the conversation on facts the other side can check, and it leaves the relationship intact for the next thing that goes wrong. Imagine, as a hypothetical, a supplier that swaps a component for a newer model. You do not need to argue about whether the swap was reasonable. You need the effect on your deliverables written down and approved before the work continues.

On a multi-city rollout for a national cinema chain, a technology partner altered its equipment specifications mid-project. I handled it through a formal change order. That sentence is short because the process is: describe the change, price it, date it, sign it.

What to record so the project can be audited

A change order that lives in someone’s inbox is half a change order. Keep a change register: one line per request, with its category, description, impact, status and who decided. The UK guidance suggests statuses such as requested, assessed, approved, deferred, implemented and closed. It also says closed changes stay on the register, with when and by whom they were closed.

Record the rejected and the deferred ones too. Six months later, when someone asks why a requirement was dropped, “it was rejected on this date for this reason” is a complete answer. This is the same point I made about automating workflows without losing control: document the why, not only the what.

One more practice from the US federal rules is worth borrowing: when the adjustment is agreed, they advise including a release of further adjustments for the same facts. In plain words, both sides confirm that this change is now closed, so it cannot come back as a surprise invoice.

A checklist you can copy

• Is the change written down, with the original agreement referenced?
• Does it say what changed and why?
• Is the cost effect stated, and the cost of not changing?
• Are the new dates stated?
• Is the approver named, with authority for this amount?
• Was the other party’s agreement obtained in writing?
• Is it entered in the change register with a status?
• Is it clear that this settles the matter, and nothing else is pending for the same cause?

The takeaway

A change order does not slow a project down. It makes a change visible, priced and approved while it is still small. This is general project practice, not legal advice: if the amounts are large or a contract dispute is likely, ask a lawyer to read your contract.

If you want this kind of structure on your own work, see how I approach project management.

Have a project that needs structure? Tell me the scope and I’ll get back to you with a concrete proposal.