The moment everyone dreads
A change order lands on your desk. It’s big, it wasn’t anticipated, and the field is already asking when the crew can move. You have two problems at once: the money and the calendar. Most people treat those as one problem. I treat them as two, and that choice changes how the whole thing plays out.
If I had to pick one decision that separates a smooth negotiation from a painful one, it’s this: do you protect the schedule first, or do you let the dollar amount drive everything? I choose the schedule first, every time.
Why I don’t let price set the pace
Here’s the thing about a large, unanticipated change order. The number is scary, so it pulls all the attention. Everyone starts arguing about cost before anyone has agreed on how the work fits into the existing sequence. That’s backwards.
Once you fix the schedule impact, honestly and early, the cost conversation gets easier. You’re negotiating from a shared understanding of what the change actually touches: which activities move, which ones don’t, and where the float is. Skip that step and you end up negotiating price against a moving target, because nobody agrees on what “delay” even means yet.
I always ask three questions before I say a number out loud:
- What does this change touch on the schedule, specifically?
- What’s critical path, and what isn’t?
- What’s the smallest scope change that still solves the actual problem?
That last one matters more than people think. A lot of change orders get bigger than they need to be because nobody pushed back on scope before pricing it.
The choice most people get wrong
The choice I see people face constantly is this: negotiate the change order fast to keep the peace, or slow down and negotiate it right. Fast feels responsible. It isn’t, usually.
A quick agreement that doesn’t nail down schedule impact just moves the argument to month three, when everyone’s forgotten the original justification and the record is thinner. I’d rather spend an extra week getting the time impact analysis right than spend two months later arguing about whether a delay was excusable, compensable, or nobody’s fault.
So my answer is: slow down, but only on the parts that need it. Don’t slow down the parts you already understand.
What a good negotiation actually looks like
A good change order negotiation has a paper trail before it has a number. That means:
Document the baseline. You need to know what the schedule looked like before the change, not from memory, from the actual schedule file with its logic intact.
Isolate the impact. Show exactly which activities shift and why, using logic ties, not just a general claim that “everything will be late.”
Price the impact you documented, not the impact you fear. It’s tempting to price in a cushion for the disruption you’re worried about. Resist it. Price what the schedule shows.
A bad negotiation skips straight to a lump sum, argued from gut feel on both sides, with no schedule fragnet to back it up. It might close faster. It also tends to reopen later, usually at a worse moment.
The trade-off nobody names
There’s a real trade-off here, and I don’t think people say it out loud enough: doing this properly costs you time up front that you don’t get back if the change order falls through or gets scoped down. You build the fragnet, run the analysis, document the logic, and then the change shrinks and half that work looks wasted.
I still think it’s worth it, for one reason. The discipline of doing the analysis is what lets you negotiate the next one faster. You’re not starting from zero each time. You’ve got a method, and the other side learns you don’t bluff on schedule impact, which means fewer of your numbers get challenged down the line.
What I actually do with the pay-off
The part people forget is what happens after the negotiation closes. Getting a fair number and a fair time extension is only useful if it holds up. I update the schedule immediately, not weeks later, and I document how the change ties back into the sequence going forward. If I don’t do that, the “win” from the negotiation quietly disappears the first time someone asks why the project is behind and nobody can point to the reason.
That’s really the whole approach: separate time from money, document before you price, and don’t let a fast agreement replace a real one.
