Insiders Take | 02 - What Good VDC Actually Looks Like

There’s a version of VDC where the model gets made, the deliverables get issued, and the people in the field don’t actually use any of it. That gap is what I think about most when I look at where this discipline is going. The way you close it isn’t by getting better at the software. It’s by translating between the digital and physical sides of a job until both sides start hearing each other. You don’t get good at that translation by living on one side of it.

Translation requires both sides

I came out of the field on a project running ten-million-dollar pay applications every month. There’s nothing that replaces those reps. When you’ve been on a team like that, you see problems through a project lens, not a software lens.

This is the part of VDC that doesn’t get talked about enough. Most of the people moving into this discipline are coming from the field, not the other way around. I’ve seen far more people go field-to-BIM than BIM-to-field, and there’s a reason for that. Modeling shapes that don’t touch each other in Navisworks and coordinating an actual install sequence safely are two different jobs. If you’ve only spent time doing the first one, you don’t know what the model is for. You’re just clicking.

A VDC person who has only lived on the digital side might produce technically clean deliverables, but that’s no guarantee the field wants to use them. It’s quite possible they are sitting behind a computer regurgitating design intent. They draft concrete drawings off the design model without ever sitting down cross-discipline to talk through how the work is actually going to get built. That isn’t an install plan. It’s more paperwork for the field crew to stand over together and try to decipher.

VDC is a business transformation problem, not a software problem. The deliverables only matter if they change how the project actually runs and how the facility actually operates.

Translation looks like teaching

In my experience, 95% of the jobs I work on require continuing education. The team doesn’t always know what BIM is for. They don’t know what to ask of me. They don’t know the difference between a model that informs the build and a model that just sits there. So a big part of the job is sitting in the trade coordination meeting, hosting the RFI design constraint meeting, walking a superintendent or PM through what’s actually being decided and why it matters at the field level.

That isn’t extra to the work. That is the work. If you skip it, the deliverables exist but they don’t move anything, and you become another person sitting at a computer doing BIM stuff while the project has no idea what it bought.

There’s a spectrum on every job. Some teams pick it up quickly and you can hum right along. Some you have to drag a little. Some you are half-dragging, quarter-pushing in a wheelchair, and the last bit they have to crawl. The job is the same either way. You’re translating one side of the project to the other until both sides start hearing each other.

Take a similar analogy to the role of a general foreman. The good ones change the course of an apprentice’s career. The bad ones make them quit a year in. Same role, completely different outcome based on whether the person showing up is willing to invest in the people who don’t know yet. Same for a VDC integrator and their perception by project stakeholders.

The metric is silence

Don’t get emergency calls from the super. That’s the highest praise you can get on a job. The team is dealing with problems all day long, and the people they respect most are the ones who quietly take problems off the queue. The job moves.

That’s what good VDC looks like in execution. The model already answered the question. The dimensions are right. The MEP routes are coordinated. The concrete drawings are vetted, the curtain wall is set back, and the late-cycle structural comment got resolved before the pour. Nobody had to call. Nobody had to firefight.

If you’re investing in VDC, the question isn’t whether your team can run the software. It’s whether the field eventually stops needing to call them.

Don’t get emergency calls. That’s the job.

-Jack