Every job is going to change. The drawings you started with are not the drawings you'll finish with. An owner walks the space and decides the conference room needs a glass wall. A concrete guy hits a utility that isn't on the as-builts. The mechanical engineer reissues a sheet three weeks after you've already roughed the ductwork. Change isn't the exception on a construction project — it's the water you're swimming in. The teams that stay profitable aren't the ones that avoid changes. They're the ones who catch them early, price them honestly, and get them into the schedule before they blow up the sequence downstream.
The trouble is that most change management lives in three places at once: a spreadsheet somebody forgets to update, an email thread nobody can find, and the superintendent's head. That works right up until it doesn't — usually around month eight, when you're arguing about whether a directive was ever priced and the guy who knew is off the job. Good software doesn't manage change for you. It just refuses to let the pieces fall on the floor. Here's what that actually looks like on a real job, and where it earns its keep.
Log the change the day it happens, not the day you bill it
The single most expensive habit in the field is waiting to document a change until you have time to "do it right." You never have time. Meanwhile the clock on your notice requirement is running — most contracts give you somewhere between 7 and 21 days to notify the owner of a condition that entitles you to a change, and blowing that window can cost you the claim entirely no matter how legitimate it is.
So the discipline is simple: the moment a field condition, an RFI response, or a verbal from the owner's rep changes what you're building, it gets a number and a timestamp. That's it. Not a full estimate — a placeholder with a date, a short description, and a photo. A running change log that anyone on the team can open and add to means the notice clock and the paper trail start on day one. When you finally sit down to price it, you're working from a real record instead of trying to reconstruct three weeks of memory. The categories to keep straight from the start:
- Contractor-requested vs. owner-directed. This one determines who pays, and it's the first thing that gets muddy. A change you requested to solve a means-and-methods problem is on you. An owner directive is billable. Tag it correctly at intake and you save yourself a fight later.
- Time-and-material vs. lump-sum. If the owner directs you to proceed before a price is agreed, you're on T&M and you'd better be tracking daily tickets with signatures. Miss a day of tickets and you eat that day.
- Design change vs. field condition vs. scope add. These bill differently and, more importantly, they carry different schedule consequences, which is the part that actually hurts.
The cost impact is the easy half. The schedule impact is where jobs die
Anybody can price the labor and material on a change. The estimator does that in an afternoon. What sinks projects is the schedule impact nobody analyzed until the work was already in the ground.
Here's the pattern I've watched play out a hundred times. A change looks small — reframe a soffit, add a few can lights. The cost is trivial, so it gets approved on the spot. What nobody traced is that the soffit change means the ceiling grid can't close, which means the mechanical trim gets pushed, which means the room isn't ready for the flooring crew who's mobilizing Monday whether you're ready or not. The $2,000 change just triggered a $30,000 sequence problem because it touched the critical path and nobody looked.
Before you approve any change, walk it forward one step at a time and ask: what predecessor did this just break, and who's the next trade waiting on that? This is exactly where a live look-ahead schedule pays for itself. When your three- and six-week windows are laid out visually and the trade-flow sequences are actually connected, you can drop the change into its location and watch what turns red downstream before you commit. A tool like LookAheadWall exists for precisely this reason — you can see the near-term collision in the weekly work plan instead of discovering it when the flooring sub shows up to a room that isn't finished. Rules of thumb worth carrying:
- Any change that touches an inspection hold point (rough-in, fireproofing, in-wall anything) needs a buffer added, not just the raw task duration. If it pushes a rough-in inspection, assume you've lost a day just to the re-inspection cycle, sometimes more depending on your AHJ's backlog.
- A change that adds work in an already-completed area costs far more than the same work in open construction. Demoing finished drywall to add a blocking detail somebody forgot is easily 3–4x the original install. Price the rework honestly and, just as important, flag whose miss it was.
- If the change lands on the critical path, the schedule cost is real project money and belongs in the change order — not just the direct cost. This is the number owners fight hardest and the number you're most likely to leave on the table.
Approvals: route it once, route it right
The reason changes stall isn't usually disagreement — it's that the paperwork is sitting in somebody's inbox who's on vacation, and nobody knows it. A change that needs the PM's sign-off under $10k and the owner's above it should route itself down the right path automatically the moment you enter the dollar amount. No hunting for who's next.
Two things matter more than speed here. First, don't let the field proceed on a change until the authorization to proceed is in writing — even a one-line "proceed on T&M, price to follow." Verbal approvals evaporate the instant there's a dispute. Second, keep every version. When the owner claims they approved a different number, the timestamped trail of who saw what and when ends the conversation in about ten seconds.
Push the approved change back into the field the same day
An approved change that never makes it to the crew is worse than useless — now two guys are building to two different sets of information in the same room. The loop only closes when the field is executing the current revision.
This is the failure mode that quietly wrecks quality. The office approves a change, updates their set, and assumes the field knows. The foreman is still working off the drawings printed at mobilization. So the framer builds the wall per the old plan, and next week you're demoing it. Every approved change needs a hard trigger that updates the field's actual working schedule and drawings — the weekly work plan the crew leaders are looking at that morning, not a PDF buried in a folder. On the mobile side, the foreman's schedule view needs to reflect the change before he stages his crew for the day. The whole point of short-interval scheduling is that what's on the wall matches what's getting built this week; a change that doesn't reach the wall breaks that promise.
Track the trend, not just the transaction
One change is a transaction. Twenty changes with the same root cause is a message you should be reading. When you keep a clean, categorized log, patterns surface that no single change order reveals.
If a third of your changes trace back to one designer's incomplete details, that's a conversation to have with the owner with data behind it — not a gut feeling. If the same trade keeps generating field conditions, either your coordination is weak or their pre-installation review is. In lean terms this is variance tracking, and it's the whole reason the Last Planner crowd measures why commitments fail. The categories that earn their keep in a monthly review:
- Cause code — design error, owner scope, unforeseen condition, coordination miss, code/AHJ. Ten changes tagged the same way is a systemic problem, not bad luck.
- Origin — which discipline or drawing set generated it. This is how you build the case for a design contingency on the next job with this owner.
- Days-to-resolve — the gap between logged and approved. A widening gap means your approval chain is clogging and changes are aging into schedule problems before anyone acts.
What a working change process actually needs
Strip away the software marketing and a change process that holds up under a claim comes down to a short list. You want a single log everyone writes to, timestamped at intake so your notice clock is protected. You want each change tagged for who pays and how it's priced before anyone touches a tool. You want the schedule impact traced forward through the connected trade flows before approval, not discovered after. You want approvals that route themselves and keep every version. And you want the approved change to land on the crew's weekly plan the same day it's signed.
None of that is exotic. It's the same discipline the best superintendents have always run out of a beat-up notebook and a sharp memory. The value of putting it in a real tool — a proper change log, a live look-ahead that shows the downstream collision, a weekly work plan the field actually reads — is that it survives turnover, it survives month eight, and it survives the day the owner's lawyer asks for the record. Change is going to happen on every job you'll ever run. The only question is whether you're managing it, or explaining it after the fact.