Nobody has ever handed me a set of drawings that survived contact with the field. On a five-story wrap I ran a few years back, the architect revised the amenity deck three times after we'd already poured the podium. Each revision looked small on paper. Each one rippled through plumbing rough-in, waterproofing, the pavers, and the railing embeds we'd already set. The change wasn't the problem. The problem was that our planning process had no clean way to absorb it, so the change hid in email threads and hallway conversations until it detonated in the field two weeks later.
That's the real question with design changes. Not how do we stop them — you can't — but how does your planning process metabolize them before they blow up a week's worth of committed work. Last Planner System software doesn't make changes disappear. What it does, when you use it right, is give the change a place to live in the plan so nobody gets surprised at the wall.
Know what kind of change you're dealing with
The first mistake crews make is treating every change the same. They're not. The handling is completely different depending on where the change came from, and a good short-interval planning process reacts to each one differently.
- Owner-directed changes come with a change order timeline attached. Money and authorization gate the work, and you often can't legally proceed until it's signed. These belong in your six-week lookahead as a constraint, not in this week's plan.
- Design development — the "details that emerge" as the design catches up to reality. These are usually smaller but they arrive constantly, and they're the ones that quietly erode your plan percent complete if you're not catching them.
- Coordination-driven changes resolve a clash between two disciplines. A duct that hits a beam, a sprinkler main that fights the light layout. These almost always affect more than one trade, so the coordination is the actual work.
- Code and regulatory changes are non-negotiable and often carry inspection implications. Treat them like owner changes on the timeline but with zero room to argue scope.
- Field-condition changes — the wall that isn't where the plans say, the existing utility nobody located. These are the fastest-moving and usually land as an RFI first.
When you name the change type, you already know roughly how long it'll take to clear and who needs to touch it. That naming is half the battle.
Trace the change all the way through the plan
A change is never just a change to one line of work. Before it goes anywhere near a weekly work plan, walk it through five questions:
- Does it add or delete activities? A revised detail might turn one framing pass into two, or add a blocking scope that wasn't there.
- Does it change durations? Bigger scope, tighter tolerance, or a harder access condition all stretch the number, and your committed dates were built on the old number.
- Does it create new constraints? This is the one people miss. A material swap can reset a procurement lead time from "in the yard" to "eight weeks out."
- Who else does it touch? The trade doing the changed work is rarely the only one affected. Follow the sequence downstream.
- Does it create rework? If the change hits something already built, you now have demo, disposal, and a re-inspection on top of the new work.
I keep a rule of thumb from years of getting burned: any change that touches already-installed work costs you at least three times the visible scope once you count demo, coordination, and the schedule hole it punches. Estimate it that way and you'll be closer to right than the optimist in the trailer.
The change is really a constraint — treat it like one
Here's the mental shift that makes the Last Planner System actually handle changes well. A design change isn't a task. It's a constraint on a task, and constraints are exactly what a lookahead process exists to hunt down and clear before work is allowed to be committed.
When a change lands, the discipline is to log its constraints immediately and put dates on them:
- Information: When will the revised documents actually be in hand? Not "soon" — a date.
- Material: Does the change alter what gets installed, and if so, what's the new lead time and who's cutting the PO?
- Coordination: Which trades have to re-sequence, and have they been told?
- Approval: Is there a change order or RFI that has to clear before anyone can lift a tool?
The whole point of pulling work through the lookahead — the three-week, four-week, or six-week window depending on how you run your jobs — is that work only advances into a committed weekly plan once its constraints are clear. A change with open constraints simply isn't ready to be made-ready. Software like LookAheadWall helps here because the constraint gets attached to the activity and travels with it week to week, so a change that landed in week one doesn't get quietly forgotten by week three. The constraint stays visible until someone kills it or the work stalls.
Protecting this week's commitments
Design changes are the number-one killer of plan reliability, and the reason is subtle. A change makes a task look the same on the board while the ground under it has shifted. The crew shows up Monday, the drawing changed Friday, and now you're improvising at the wall — which is exactly the improvisation the weekly work plan was supposed to eliminate.
When a change hits your current week, run the drill in order. Assess the impact on already-committed work. Pull or modify any commitment the change undermines — pulling a task you can no longer do reliably is not a failure, it's the system working. Add the new work the change requires, but only if its constraints are actually clear; otherwise it goes to the lookahead, not this week. And communicate it the same day, not at the next weekly meeting.
One thing that matters for team trust: when you measure plan percent complete at week's end and a task failed because of a design change that dropped mid-week, categorize that variance honestly as a change-driven miss. Don't let it count against the foreman who never had a fair shot at it. Blaming a crew for a task the owner rescoped on Wednesday is how you teach everyone to pad their commitments and stop being honest on the board.
RFIs, submittals, and change orders live on their own clock
Most design changes are tangled up with paperwork that has its own timeline, and the timeline is usually the long pole. An RFI might take a week or two to come back. A resubmittal on a changed product can run weeks. A change order has pricing, negotiation, and owner approval baked in before anyone signs.
The move is to link the field constraint directly to the document status, so the person planning the wall can see that the answer is still pending and doesn't commit the work prematurely. If a task is waiting on an RFI response, that dependency should be sitting right on the activity in your lookahead, not living in an RFI log that only the PM ever opens. When the RFI comes back, the constraint clears and the work is free to pull into a weekly plan. When it's late, everyone can see the wall it's about to hit.
A practical caution on change orders: never let the commercial process quietly authorize field work. I've watched crews start changed work off a verbal "we're good" and then eat the cost when the CO stalled in pricing. Keep the formal authorization as a hard constraint on the activity. If it's not signed, the work isn't ready — full stop — unless you've made a deliberate, documented decision to proceed at risk.
Don't forget the subs
Your subcontractors feel every change harder than you do, because they're staffing to a plan you gave them. A change that costs you a day of resequencing can cost a sub a mobilization if their crew shows up to work that isn't ready. Get the change to affected subs early — the moment you know it's real, not the moment it's fully priced — and be clear about three things: what changed in their scope, whether it carries a change-order implication, and how it moves their dates.
This is where trade-flow sequencing earns its keep. When your plan actually shows the handoffs between trades in each location, you can see at a glance which subs sit downstream of a change and pull them into the conversation before their trucks are already rolling. A shared, current schedule they can see on their own — including the crew leaders looking at it on their phones in the field — beats a flurry of "did you get my email" calls every time.
Learn from the pattern, not just the incident
Any single change is noise. The pattern is signal. If you're tracking change-driven variances separately in your weekly plan-percent-complete reviews, after a couple of months you can see the shape of your problem. Are most changes coming from one design discipline that never finished coordinating? Are they clustering at a specific project phase — say, every time you hit a new floor of a repetitive layout? Is a particular type of change eating a disproportionate share of your reliability?
That analysis is where the real money is. Some changes you genuinely can't prevent. But a recurring coordination clash between the same two trades on every floor is a fixable process problem, not fate — and you only see it because you bothered to categorize the variance instead of just absorbing the hit and moving on.
The bottom line
Design changes are inevitable. Disruption is optional. The difference is whether your planning process gives each change a place to land — named by type, broken into constraints with real dates, linked to the paperwork it's waiting on, and communicated to every trade it touches the same day it's real.
Do that consistently and a change stops being the thing that ambushes you at the wall on Monday morning. It becomes just another constraint you clear before the work is allowed to be committed — which is exactly what a short-interval planning process was built to do. The drawings will keep changing. Your plan doesn't have to keep breaking.