One Spec Change. Four People. Six Days. Track a Revit Change Without the Group Project.

The CFM Number That Nobody Agrees On

A spec change lands on a Tuesday. The mechanical CFM figure moves on a rooftop unit, and everything connected to it has to move with it: the duct sizes, the structural support, the electrical feed, the sheet that shows it. Four people open four different files. The coordinator has a list in a spreadsheet. The modeler has geometry in Revit. A project engineer has a marked-up PDF from the last coordination call. The mechanical sub has a note in an email chain that nobody can find by Thursday.

Six days later you have a reconciled answer. The change itself was one line in a spec. The labor spent chasing it across four desks was worth more than the problem the change was ever going to cause. Nobody did anything wrong. The work simply lived in too many places at once, and a late change forced every copy to be checked against every other copy.

This is the real cost of a CFM number that nobody agrees on. It shows up in your overhead, so it never gets counted. You just feel it as the week where nobody got ahead on the next package, and as the clash that surfaced on site because the duct change was never matched against the steel.

If you want to know how to track a change in a Revit model in a way that survives a late spec change, the answer is not a faster meeting. A faster meeting about the wrong version is still wrong. The answer is one record of the project that everyone reads from, so the change happens once and every consequence downstream of it is visible on its own.

That is the whole idea here. Publish from Revit, keep every revision as a version, and let a CFM change be an edit with an owner instead of a project.

Track the Change the Moment You Make It, Not the Week Before the Freeze

Most teams treat a model review as an event. It happens at 60 percent, again at 90, and once more the night before the coordination freeze. Each pass is a rebuild. Someone exports a set of views, pastes the notes into a workbook, matches them against the last meeting minutes, and hands it to a senior coordinator to sanity-check. The model changed between passes, so the notes have to be rebuilt from scratch every time.

The better habit is to publish continuously. You change the unit, you publish from the model, and the snapshot is there. When a level moves, the comparison shows it. When a family gets swapped, the change appears before anyone remembers to ask about it. Coordination stops being a look-back and becomes a read-out of the model as it stands right now.

Concretely, this is what one live record looks like. You keep your model in Revit and your federated model in Navisworks. You publish straight from the model. BidLight stores each publish as a versioned snapshot with its own files, author, and milestone. When the design changes, you publish again, and any two revisions compare element by element, grouped by category: structural, MEP, envelope, interior.

The point is not that software works faster than a person. The point is that the change nobody has to reconcile is a change nobody argues about. The CFM number stops being four opinions because there is only one place it lives.

On a live job that is the difference between a 90-minute coordination meeting and a 15-minute look at the comparison, and the 15-minute version is the one you can do while the architect is still on the phone deciding what the final spec should be.

What Four People and Six Days Actually Buys You

Trace the six days and you see where they go. Days one and two are discovery. Finding the current model, the current issue list, and the most recent marked-up PDF. Day three is reconciliation. Comparing the three versions, deciding which CFM is real, and writing down why. Day four is chasing owners. Day five is review with whoever signs off on the change. Day six is cleanup, and the cleanup happens because day one was done badly.

None of that work is coordination. It is bookkeeping of records that should have been one record. When teams describe the pain of late changes, this is what they mean. The change itself is small. The bookkeeping around the change is the cost, and the lost time is where the idle crews come from. A clash that sits unresolved can burn $15K to $50K a week in idle field labour.

Compare that to a workflow where the model is the record. The change is an edit. The comparison updates because it reads the same geometry. The issue pins to the rooftop unit and carries the sheet and revision that raised it. The electrical lead and the structural lead each have an item with their name on it. You spend your six days on the next package instead of reconciling the last one.

That reclaimed time compounds. Many coordinators lose about 11 hours a week working out which model version is current. Across a year and a team, that is thousands of hours of reconciliation that never appears on a job cost report. It shows up as issues you did not chase and a senior coordinator who is tired of being a copy-paste machine.

The value of tracking the change continuously is not just the answer. It is that the answer arrives with its own paper trail, so review takes an hour instead of a week.

The Trust Question, Answered Plainly

The fair objection is trust. If a comparison tells you what moved, how do you know it caught the mechanical scope? Here is the honest answer. BidLight compares published revisions element by element. If the unit was in the revision, it is in the list. It does not run automated clash detection, and it does not decide what matters. People do that. What it removes is the hunting, so the people can spend the time on judgment.

That is not a claim of perfection. It is a claim about where your hours go. The part that needs a human eye is exactly the part a senior coordinator should be touching: the odd assembly, the mislabeled family, the scope that needs a decision. The rest is tedious matching that eats a week and produces no insight.

If you are comparing this to the traditional path, this is the honest trade. Manual coordination gives you control and demands that you build that control from scratch on every job. A model-driven record gives you a live view and demands that you publish often enough to keep it current. The disciplines are different. The second one is much cheaper per change.

The same logic explains what 4D means in daily work. It is not a report you generate after design. It is schedule riding on the same model from the first sketch onward, so the sequence view and the coordination view are reading the same geometry. When that holds, a change is a change everywhere at once. When it does not hold, you get four people, six days, and a CFM argument.

And when a trade asks how you reached a decision, you open the issue and show them. That is a defensible answer, which is worth more than a fast one. Closing an issue takes a screenshot, a tagged user, and the model commit that fixed it. A closed issue means something.

What the Change Frees Up, and Why It Turns Into a Billable Service

Once a late CFM change costs you 15 minutes instead of six days, something else happens. The change review becomes something you can hand to a client early, when they are still deciding, because it is cheap to produce and cheap to revise. You stop treating early review as a favor and start treating it as a service with a fee.

That matters for the kind of work you win. A firm that can answer "what does this touch" on the spot in a 60 percent meeting is the firm the client calls first. When your record travels with the model and updates with every publish, you are not asking the client to wait for a week while you rebuild. You are showing them the consequence of the decision they are about to make.

The cost control follows from the timing. A clash caught in the model costs about $50. The same clash found in the field costs $5,000 to $50,000. Same conflict, two orders of magnitude, and the only difference is when you saw it. That is why the 4D view and the change record belong to the same project record.

Internally, the same record answers questions you currently pay people to answer. Who changed that rooftop unit? Which sheet did the revision come from? Which issues are still open against it? Instead of asking three people, you read the history. Same discipline, one place.

And the 6am digest means nobody has to be chased. Each owner gets what they own at the start of the day. If the mechanical lead is behind on the duct changes, you see it while there is still schedule to move work, not three weeks after the slip started.

The win is not the software. It is the hours back, the rework that never happens, and the early review you can now invoice instead of give away.

How to Start Without Ripping Out Your Current Process

You do not need to change how you draw. Keep modeling in Revit. Keep coordinating in Navisworks. The change is downstream. Publish the model and let BidLight store the version. You get a comparison back in minutes, and you keep your usual review step on top.

Start with one package, ideally the mechanical scope that hurt you last time. Publish two revisions from the live model, compare them, and look at where the list differs from what your team caught by hand. That comparison will teach you more about your own process than any demo will, and it costs you an afternoon.

Then decide how much you want on the model. Plans run from Basics at $260 per licence per year to Max at $590, with custom Enterprise terms for firms that want them. Every plan includes unlimited projects, which matters when you are coordinating twelve packages instead of one. If you would rather not run it yourself, BidLight also does done-for-you BIM work: execution plans, 4D sequencing, and fabrication detailing and spooling.

The goal is not a new process. It is one record of the project that lives with the model, so the next spec change is an edit instead of a fire drill. One live record inside Revit, with every export versioned and every change diffed, means the CFM number stops being a group project, and the week goes back to work you can finish.