The owner stood in the half-framed kitchen, pointed at where the island would go, and said the four words that start every change order: “Can we move that?” The super said sure, we can move that. And in that moment — casually, between a coffee and a slab pour — the job changed. Not just the kitchen. The plumbing rough-in moved, which moved the slab penetrations, which leaned on the schedule, which would land on the next pay app. Six weeks later an invoice came in billing the old island location, the framer wanted a back-charge for building it twice, and nobody could find the text where the owner said yes.
A change order is rarely one document. It’s a small earthquake that runs through the whole set — the plans, the spec, the contract, the schedule, the budget, and eventually the invoice. Writing the change down is the easy part. The part that quietly eats margin is keeping that one change tied to everything it touches, so nothing affected slips through and you never pay against scope that has since moved.
Most teams track change orders in a log — a spreadsheet, a tab in the PM software, a folder of PDFs. The log answers “how many” and “how much,” and for that it earns its place. What a log won’t do is hold the change order connected to the Rev C drawing it modified, the spec section it superseded, the two days it added to the schedule, and the line item an invoice will later bill against. Those connections live in people’s heads. Heads forget.
A change order is a knot, not a line item
Take CO #14: relocate the kitchen island four feet, swap the spec’d quartz in 09 30 00 for a slab the owner picked out at the yard, add a second sink. As a log entry that’s one row — “CO #14, +$3,200, +2 days, approved.” Pull the thread, though, and the knot opens. The architect issues a revised plan — A-201 Rev C. The finish schedule changes. The plumber’s rough moves and kicks off RFI #22 about the new slab penetration. The two days push into the cabinet delivery window. And the countertop allowance the contract still names is now wrong.
Miss any one of those threads and you get a specific, expensive failure. Miss the Rev C link and the framer builds to the old plan. Miss the spec supersession and the installer orders the quartz the contract still calls out. Miss the schedule tie and the cabinet truck shows up to a slab that isn’t ready. Miss the invoice link and — the classic — you pay the original countertop line plus the change, billing the same scope twice.
The change order is easy to write down. The expensive part is keeping it connected to everything it just changed.
The real risk: paying against stale scope
Every change order forks the truth. Before CO #14, the correct countertop is the quartz in the contract. After it, the correct countertop is the owner’s slab on A-201 Rev C. For a window of weeks both versions are live on the job — the old one in the original contract and the spec book, the new one in the change order and the revised drawing. Invoices get cut against whichever version the billing person happened to be looking at, and that’s where money leaks. A pay app comes in for the rough plumbing at the contract quantity, but CO #14 already moved that rough and repriced it; nobody walks the invoice line back to the change order, so it gets approved at the old number. The defense is boring and absolute — before you approve a dollar, trace the invoice line back through any change order that touched it, to the Rev and the spec section that govern it today.
How to keep a change order connected
- 1
Capture the change with its origin
Write the CO number, the scope, and where it came from — the email, the text, the meeting. The approval is the anchor; without a traceable yes, the rest is hearsay.
- 2
Map what it touches
List every document the change forks: which drawing gets a new Rev, which spec section it supersedes, which RFIs or submittals it answers or reopens.
- 3
Link the revisions explicitly
Tie CO #14 to A-201 Rev C and to the superseded spec line, both directions. The old version stays in history, flagged as overridden — never deleted.
- 4
Push it into schedule and budget
Record the days added and the dollars moved, and connect them to the activities and cost codes affected — not as a lonely number on a side log.
- 5
Reconcile every invoice against it
When a pay app or invoice arrives, trace each line back through any CO that touched that scope and confirm you’re billing the current version, not the stale one.
The discipline is sound. The problem is that steps two through five depend on someone remembering, weeks apart, that CO #14 ever existed — and remembering it across a plan set in one app, a spec book in a binder, a schedule in another tool, and invoices that arrive by email from three different subs. The change order is one knot, but its threads run through five places that don’t talk to each other.
Where a shared project memory earns its keep
This is the gap BRAD is built for. You already forward the documents and messages that run the job — the change order, the revised drawing, the spec PDF, the schedule update, the invoices, and the text where the owner said “can we move that.” BRAD reads them and connects them into one record, so CO #14 isn’t a lonely row in a log; it’s wired to A-201 Rev C, to the superseded line in 09 30 00, to RFI #22, to the two-day slip, and to every invoice that bills that scope. Then you ask in plain language, over the same email or text you already use — no new dashboard to learn. “What does CO #14 affect?” comes back with the revised drawing, the spec it superseded, and the RFI, each with the source attached. “Has anyone billed against the old island location?” pulls the invoice lines that reference the original scope and shows the change order that should have repriced them — with citations, so you open the actual documents and decide. BRAD doesn’t replace the contract’s formal change process, a stamped drawing, or a signed change order, and it doesn’t make the call on whether to pay an invoice. A person still owns that decision and the licensed judgment behind it. What it does is make sure that when you make the call, every document the change touched is in front of you with its source, instead of scattered across five tools and someone’s memory.
The island moved in one sentence. Everything it dragged with it — the drawing, the spec, the schedule, the pay app — moved silently, and that silence is where the money goes. Track the change as a knot, walk every thread before you sign or pay, and the back-charge six weeks out never gets written.