Price the Change Before Your Crew Touches It

A change order process is the short, written loop a job runs every time the work changes: define the new deliverable, price it, get the approval in writing, then let the crew touch it. It exists because extra work priced after it is finished gets priced badly. A project controls lead at a mechanical contractor put the cost in one line: some contractors let those extra work values pile up and negotiate them at the end of the job, and "they always take a hit."

Why Does Extra Work Settle at the End, and Why Does It Cost You?

Nobody decides to defer the money, it happens one favor at a time. A wall opens up and there is rot behind it, a spec part is unavailable, the client's site manager asks the foreman for two more circuits while he is standing right there. Each one is too small to stop the job over, so the crew does it and somebody says they will write it up later.

Later is closeout, and closeout is the worst negotiating position you will ever hold. The work is done, so you cannot decline it. The hours are old, so the client questions them.

Extra work you have not priced is not revenue yet, it is a debt you will collect from the weakest position you will ever hold.

The contractors who avoid this are not better negotiators. They close the loop while the client still needs something from them.

What Does a Change Order Process Need?

A change order process answers six questions in writing before the work happens. Most contractors have three of them living in somebody's head and the other three living nowhere at all.

1. What triggers it. The conditions that make something a change rather than a favor: a field change order, an additional work request, discovered conditions, a substitution.
2. Who defines the deliverable. One person writes what the extra work is, in the language your scope of work already uses.
3. Who prices it. The estimate comes from whoever owns estimating, not from a foreman guessing at the tailgate.
4. Who approves it, on both sides. A name on your side, a name on the client's, and a rule for when the client's name is unreachable.
5. Where the paper lives. One place, filed against the job, findable by someone who was not there.
6. What it does to the schedule. The date impact, stated before the change is accepted.

Only one of the six is about money. The rest are authority and sequence, which is why change orders fail as a form and work as a procedure. Our guide to writing an SOP people can follow is the right container for it: purpose, decision points, then steps.

Route the Change Through a Compressed Front End

The fix the project controls lead described invents nothing. A change is a tiny job, so run it through a compressed version of the front end you already run: define the deliverable, estimate it, approve it, then work. Your bid process does this over three weeks; the change loop does it in a day, with the same four gates in the same order.

If a step would be skipped in the compressed version, it probably should not be in your bid process either. A front end that cannot be compressed is usually padded, and a compressed one that drops the estimate is not a process. When we map an estimating process end to end, the change loop is the same map at smaller scale, which means your team already knows how to run it.

Get the Approval in Writing Before the Crew Moves

Written approval before execution is not a paperwork preference. It is the only moment when both parties agree on what the work is worth, because neither knows yet how hard it turned out to be.

Verbal approvals are the common failure. The site manager says go ahead, the foreman goes ahead, and at closeout that manager remembers a conversation about something smaller. Nobody is lying: a verbal from four months ago is just not evidence.

The practical version is short. The field writes the change up on a standard form the same day it appears, estimating prices it, someone with authority on the client's side approves in writing, and the approval is filed against the job number instead of an inbox. Your SOPs for the field should carry the form and the wording, so a foreman is not composing an approval request from scratch at 6am.

The crew does not start until the approval lands, unless someone senior says otherwise. That exception has a name.

At-Risk Work Needs a Name Attached to It

At-risk work is work you start before the contract change is actually executed. A contract modification is the client's formal amendment to your contract, the document that makes the extra work billable. Working at risk happens, it is sometimes correct, and it must never be a field decision.

Timing forces the issue. A contract modification generally takes about a month to come back, and jobs do not pause for a month, so the crew keeps going and the company spends money it cannot yet bill. An estimating director we worked with set a hard rule: anyone still working before the modification arrives is working at risk and must escalate for approval first.

The rule is not "never work at risk." It is that at-risk work carries a name, a date, and a dollar ceiling, because somebody with authority took the exposure knowingly. A foreman quietly continuing because stopping felt awkward is not a decision, it is a leak, and it is the same family as every other undocumented judgment call in a construction business that runs on what people remember.

One more instruction: the moment anyone senses the job will run over, the client hears about it. Not at the next milestone. When the sense arrives.

Present the Math, Not the Demand

When the fee will not cover the rest of the job, you present the math and then you stop talking. An estimating director dictated this script to us word for word, because his team kept skipping the arithmetic and going straight to the ask, which lands as a demand.

The sequence is four numbers and a date. State the current burn rate, what the job spends per month, then the remaining fee. Divide the fee by the burn rate for the months of money left.

Put that date next to the project's projected end date and let the gap sit in the open.

Then stop, and offer options instead of an invoice. A contract modification might not be what the client needs: "I don't like to be forceful and saying you must give us a contract mod."

So lay out the choices. Work slower and stretch the money. Run out and stop. Or the client moves money around inside their own budget, a door you cannot see from outside.

A client can almost always solve a funding gap in a way you would never have thought to propose.

Define the two terms in the document itself. Burn rate is monthly spend, and estimate at completion is what the job will have cost when it is done. A team that cannot produce both on request defaults to the ask, which is why an internal case for a systems investment fails when it leads with the number it wants.

Track What the Change Did to the Schedule

A priced and approved change is half accounted for until you know what it did to the dates. Most contractors track changes in dollars and absorb the time silently, which is how a job lands late with a fully approved budget.

This hurts more than it should because most schedules are built to a single finish date rather than to the client's deliverables. When the owner asks when one system comes back online, the only answer available is when the whole project finishes. Building the schedule around the client's deliverables is what makes change impact answerable at all.

So the last field on the form is the smallest and the most often blank: days added, and to which deliverable. Fill it in at approval, not at closeout.

Do not write the whole procedure this month. Take the last three changes on your current job and write down who approved each one and where that approval sits. In the interviews we run with contractors, that hour finds the leak faster than an audit. The Systems Effect sits in those interviews and turns what the field already knows into SOPs a new foreman can follow.

Frequently Asked Questions

What is a change order process?

A change order process is the written loop a company runs whenever work changes mid-job: define the new deliverable, estimate it, get written approval from a named person on both sides, then execute. It is the front end of a full bid, compressed. The point is sequence, because extra work is only negotiable while it is unbuilt.

How do you stop doing extra work for free?

Price and approve it in writing before the crew executes, with no exception that lives outside the document. Work settled at closeout always settles low, because the job is finished and your leverage is gone. Give the field a standard form, a same-day rule for filling it out, and one named person who prices it, so declining unpriced work is a procedure rather than a personality.

What is at-risk work?

At-risk work is work you begin before the contract modification is executed, so you are spending money with no signed authority to bill it. Since a modification generally takes about a month to come back, it is sometimes the right call. It is acceptable only when someone senior has approved it by name, with a date and a dollar ceiling, and never when a foreman decides it alone in the field.

How do you tell a client the fee will not cover the rest of the job?

Raise it the moment you sense the overrun rather than at the next milestone, because a contract modification takes roughly a month to come back and waiting puts somebody at risk. Then show the arithmetic before the ask: current burn rate, remaining fee, fee divided by burn rate for months of money left, and that date against the projected end date. Stop there and offer options, which are to work slower, run out and stop, or move money around inside their own budget. Leading with the demand costs you the answer the client would have offered on their own.