Why So Many Change Orders Trace Back to the Same Handful of Interface Points

Why so many change orders keep tracing back to the same handful of spots on a set is a question worth asking literally, not rhetorically. Plot where change orders actually originate on a large commercial or industrial project and the pattern isn't a scatter — it's a cluster. The same interface points fail project after project, asset class after asset class, because the reason they fail isn't bad luck on any one job. It's structural: those are the places where nobody, by default, owns checking one discipline's work against another's.

That distinction matters for what an owner does with the finding. If change orders were genuinely random, more inspection everywhere would be the only lever available. They aren't random. They concentrate at identifiable seams — and a review scoped to check those seams specifically catches a disproportionate share of the exposure sitting in a set, before it's ever priced.

What Counts as an "Interface Point"

An interface point is any place on a set where two things drawn by different people, on different sheets, sometimes on different schedules, have to agree with each other and don't automatically get checked against each other. It's a different category of error than a mistake inside one discipline's own work. A structural engineer who misreads a load case has made an error a structural QA/QC pass is built to catch. A duct routed through a beam nobody cross-checked against the structural sheet is a different kind of failure — each sheet can be internally correct and the conflict still exists, because it lives in the gap between the two sheets, not inside either one. That's the same gap covered in why "it passed QA/QC" doesn't mean the set is coordinated: interface conflicts are structurally invisible to a review process organized around single disciplines.

Why the Failures Cluster Instead of Spreading Evenly

A January 2025 U.S. DOT Project Delivery Center of Excellence report grouped construction change order root causes into three buckets: the quality of technical project development work, organizational culture around raising and resolving issues, and financial uncertainty outside the project team's control — the same framework covered in more depth in why so many change orders happen. Interface points sit almost entirely inside that first bucket, and they're the part of it that concentrates rather than spreads, because the same handful of boundary conditions repeat on every set of comparable complexity: the same discipline pairs, the same document types, the same handoff moments in the schedule.

The Construction Industry Institute's IR-153 benchmarking data, drawn from 144 industrial projects, puts direct field rework at roughly 5% of total project cost on average, with the 90th percentile of projects running as high as 12.4% — and design-stage rework adds another 1 to 3 percentage points on top of the field number. That spread between the average project and the 90th-percentile project isn't explained by wildly different luck. It's explained by whether the recurring interface points on that particular set got checked before bid or got found in the field.

The Interface Points That Show Up Again and Again

These aren't evenly distributed across the discipline list. A handful of boundary conditions account for most of the recurring failures:

• Structural-to-MEP boundaries — duct, pipe, and conduit runs drawn against structural framing developed on a separate track, the highest-frequency clash category on nearly any set of real complexity, broken down in detail in where structural and MEP conflicts actually originate and ranked by failure frequency in the interface points that fail most often.
• Spec-to-drawing boundaries — a written spec section describing one assembly while the paired drawing detail shows another, a gap that exists because the spec and the drawing are frequently developed and finalized by different people on different timelines, covered section-by-section in the five spec sections most likely to disagree with the plans.
• Structural-to-architectural boundaries — slab edge conditions, control joint layouts, and embed plate locations that the architectural finish plan and the structural framing plan each show independently, with no default step that reconciles the two before issue.
• Civil-to-building boundaries — grade elevations, utility stub locations, and building pad conditions established on the civil set that don't get re-verified against the architectural and structural sheets once the building design has moved on from its early massing.
• Schedule-to-detail boundaries — a door schedule, hardware schedule, or panel schedule that drifts out of sync with the detail or one-line diagram it's supposed to match, usually because the schedule gets revised on its own late in the process without a corresponding sweep back through the details that reference it.

Every one of these is a boundary between two things that were drawn by different people, on different timelines, with no default checkpoint that puts them side by side before the set is issued. That absence of a checkpoint — not the underlying technical difficulty of getting either side right — is what makes the same interface points fail on project after project.

Why the Same Boundaries Keep Failing on Every New Project

If interface points were a difficulty problem, they'd fail unpredictably — hard sets would fail more, easy sets less, and the specific location would vary. That's not the pattern. The same boundaries fail across an unrelated data center, an unrelated multifamily building, and an unrelated healthcare renovation, because the organizational structure that produces the gap is identical across all three: each discipline's sheets get their own internal QA/QC pass, each discipline finalizes on its own schedule, and nobody's job description includes checking discipline A's sheet against discipline B's sheet as a standalone task. Ownership sits inside each discipline. It doesn't sit at the boundary between them, which is exactly the ground the Marzuki study's "coordination" and "management" categories describe — the interface problem isn't that either side did bad work, it's that nobody was assigned the seam itself.

Schedule pressure makes the pattern worse without changing where it shows up. When a set has to move to bid on a fixed date, the first casualty is almost always the cross-discipline check — not because anyone decides coordination doesn't matter, but because a single-discipline QA/QC pass has an owner and a deadline, and a cross-discipline check frequently doesn't have either. The interface points don't move. They just go unchecked more often under pressure, which is why the exposure sitting in a rushed set tends to be concentrated in exactly the same handful of places as a set built on a normal schedule — just less likely to have been caught before issue.

Catching Interface Points Before They Become Change Orders

Because the failure points are predictable, the fix doesn't require reviewing every line on a set with equal intensity. It requires a reviewer whose specific job is to check each of these known boundaries — structural against MEP, spec against drawing, structural against architectural, civil against building, schedule against detail — deliberately, as a distinct pass, rather than hoping a single-discipline review incidentally catches a conflict that lives outside any one discipline's scope. That's a categorically different exercise than asking each engineer to double check their own sheets; it's reading the full issued set with the explicit goal of finding where the boundaries disagree.

Preempt Global's document review is built around exactly that list of recurring boundaries: drawings and specs checked across every discipline, with the known interface points treated as a standing checklist rather than a hope that someone happens to notice, delivered within 48 hours and backed by a $50,000-exposure-or-free guarantee. That guarantee holds up as a business model for the same reason this pattern repeats project after project — the same handful of interface points are sitting in sets of this size and complexity right now, in the same predictable places, whether or not anyone has looked yet.

Frequently Asked Questions

Why do change orders keep coming from the same types of conflicts across different projects?

Because the underlying cause is organizational, not project-specific. Each discipline runs its own QA/QC pass against its own sheets, on its own schedule, but no default process checks one discipline's sheets against another's at the boundary between them. That organizational gap is identical across unrelated projects, which is why the same handful of interface points — structural-to-MEP, spec-to-drawing, structural-to-architectural — fail again and again regardless of asset class.

Is an interface point conflict a design error or a coordination failure?

Usually both, but the distinction matters. Each side of an interface conflict can be internally correct — a duct sized right for its load, a beam sized right for its span — and the conflict can still exist because the two were never checked against each other. That makes it a coordination failure first: the technical work on either side of the boundary is often fine, but nobody reconciled the two before the set was issued.

Can a discipline's own QA/QC process catch interface conflicts on its own?

Not structurally. A discipline's QA/QC checks that discipline's sheets against that discipline's own standards, which by design doesn't extend to a different discipline's sheets. A structural engineer's QA/QC pass isn't scoped to check the mechanical drawings, and vice versa — which is exactly why interface conflicts survive discipline-level review and only surface once someone reads both sides against each other.

How much does catching an interface conflict early actually save compared to catching it in the field?

Published rework benchmarking (CII IR-153) puts average direct field rework at about 5% of total project cost, rising to 12.4% at the 90th percentile of projects — largely driven by how many of these interface conflicts were caught before bid versus discovered during construction. A conflict found on paper is a redline; the same conflict found in the field means reconciling installed work, revised submittals, and often schedule delay against a price that was already locked in.

---