The moment the schedule breaks
Every project has a day when the plan stops matching reality. A drawing conflict shows up in the field. A subcontractor hits rock where the geotechnical report said soil. Someone finds out the switchgear that was supposed to ship in six weeks now takes six months. Whatever the cause, the result is the same conversation: a large, unanticipated change order that nobody budgeted for and nobody wants to explain up the chain.
I have sat across the table for a lot of these. The pattern is always the same. The first instinct is to treat it like a fight, one side trying to prove the change is real and necessary, the other side trying to prove it is smaller or cheaper than claimed. That instinct is understandable. It is also the slowest way through.
What the change order is actually asking
A change order is not really a request for money. It is a request to answer three questions at once: what changed, what it costs to fix, and what it does to the finish date. Most delays in resolving these come from people trying to answer all three in one sitting, usually in a room with people who are already frustrated.
I split them apart on purpose. Scope first: what is different from what was priced originally, in plain terms anyone could understand without the drawings in front of them. Cost second: built from a clear basis, not a lump sum that shows up with no backup. Schedule last: because the schedule impact almost never matches anyone’s first guess, and guessing early just gives you a number to defend instead of a number to trust.
Where the negotiating actually happens
The negotiating part is not the argument over price. It is the work of tracing a change back to its actual cause and being honest about which party’s decisions produced it. If a design gap caused the problem, that gets said plainly. If field conditions changed after the contract was priced, that gets said too. Nobody wins by inflating the other side’s error or shrinking their own.
What I have found is that the parties who get through a large change order fastest are the ones who stop trying to win the conversation and start trying to finish it. That means bringing documentation before being asked for it. It means separating the change that is not in dispute from the piece that is, so at least one part can move while the argument continues on the rest. And it means being willing to concede a point early if the paper trail supports the other side, because credibility on the small points is what buys you the benefit of the doubt on the big one.
Protecting the finish date while the argument continues
The part people miss is that the negotiation and the schedule are two separate problems, and they do not have to wait on each other. A change order can take weeks to fully price out. A project cannot always afford to sit idle for those weeks. Where possible, I look for a way to keep the unaffected scope moving while the disputed piece gets resolved on its own track. That takes some discipline in how the schedule is built, because it means the logic has to allow pieces of the project to separate without falling apart.
This is where a tool like Primavera earns its keep. Not because software resolves disputes, but because a schedule that is actually maintained, with real logic ties and real float, gives you a fast, credible answer when someone asks what a proposed delay does to the finish date. Without that, every schedule question during a negotiation becomes its own mini-argument.
What minimal impact actually looks like
Minimal impact does not mean no impact. It means the project absorbs what it has to and loses nothing it does not have to. That is a lower bar than people think, and it is achievable more often than the initial panic over a large change order suggests.
The habit I would tell anyone to build is this: treat the change order as a documentation problem before it becomes a negotiation problem. Write down what changed while it is still fresh. Get the cost basis built before the number becomes a talking point. Keep the schedule current so it can answer questions instead of raising more of them.
None of that makes the conversation easy. It makes it shorter, and it makes the outcome something both sides can actually live with once the project moves on.
