How to Brief a BIM Team Properly So You Get the Model You Actually Need

I want to be honest with you about something uncomfortable.

When a BIM project goes wrong, the first instinct is to blame the BIM team. The model is not what was expected. The coordination missed things it should have caught. The deliverable arrived and nobody could quite use it for what they needed. And sometimes, yes, that is on the team. But more often than anyone in the industry likes to admit, the BIM team delivered exactly what they were asked for. The problem was that nobody asked for the right things clearly enough.

I have watched this play out repeatedly. A client walks away frustrated with a model that does not serve them. The BIM team is confused because they did what the brief said. And somewhere in the middle, there is a briefing conversation that was too short, too vague, or involved the wrong people.

Getting a BIM model that actually works for your project starts before anyone opens a software package. It starts with a proper conversation. Here is what that conversation needs to cover.

Start With Why, Not What

Every brief I have seen that went wrong started with deliverables. Give us a coordinated model. Give us a federated file. Give us a full BIM drawing set.

These sound like clear instructions. They are not. They describe outputs without explaining what those outputs need to do. And that gap, between what a thing looks like and what it needs to do, is where projects go sideways.

Before you talk about deliverables, talk about purpose. Why does this model exist? Think about it seriously for a moment. Is it primarily there to catch clashes between structural and MEP before they hit site? Is it going to drive quantity takeoffs that feed into cost planning? Is it going to be handed to a facilities management team on completion day and used for the next twenty five years? Is it feeding into structural analysis software? Is the client going to see phasing visualizations from it?

Every one of those purposes changes how the model gets built. Not slightly,  fundamentally. A model built to serve FM handover needs data richness that a clash detection model does not need. A model built to generate quantities needs family parameters that a visualization model never uses.

When the BIM team does not know why the model exists, they guess. Their guesses are based on the last project they worked on, not yours. And their guesses might be completely wrong for your situation.

So the very first briefing question is this. What does this model need to do, for whom, and when does it need to do it?

Have the LOD Conversation Properly

Level of Development sounds like a technical detail. It is actually a budget decision dressed up in technical language.

LOD controls how much detail goes into the model at each stage of the project. Higher LOD means more detail, more time, more cost. And here is the thing that briefs rarely acknowledge,  higher LOD is not always better. It is only better when that detail is actually going to be used by someone.

Asking for LOD 400 everywhere sounds thorough. In practice it often means paying for fabrication-level detail in areas where nobody ever needed it. Most projects need LOD 300 for the majority of the model, with targeted LOD 400 in specific areas where fabrication coordination is actually critical. The difference in cost between those two approaches is real and meaningful.

Have this conversation out loud with the BIM team. What does each discipline actually need to show at each project stage, and for whose benefit? Be honest about what you need rather than asking for the most thorough-sounding option. The BIM team can then plan the work properly, price it accurately, and spend the detail budget where it actually makes a difference.

Write Down Every Discipline. Every Single One.

I cannot tell you how many scope disputes on BIM projects come from discipline scope that was implied rather than stated.

The client assumed MEP was included. The BIM team understood they were modeling architecture and structure only. The clash detection runs without MEP. The conflicts that would have been caught in a coordinated model show up on site six months later, at ten times the cost.

That conversation takes five minutes to have properly at the briefing stage. It takes weeks to manage when it surfaces as a site problem.

Go through every discipline involved in the project. For each one, be explicit. Is the BIM team modeling it? Are they receiving a model from an external consultant and coordinating against it? Is it outside the scope and being handled elsewhere? Write it down. Put it in the brief document. Get the BIM team to confirm they understand it.

Anything left implied in a brief will eventually cause a problem. The only question is how expensive that problem will be.

Understand That Modeling and Coordination Are Not the Same Thing

This confusion causes more disappointment than almost anything else on BIM projects.

Modeling is building the geometry. It produces a model. Coordination is the ongoing process of bringing all the discipline models together, checking them against each other regularly, running meetings where people actually sit down and resolve the conflicts, tracking those resolutions, and making sure the changes flow correctly back into every discipline’s model.

Modeling without coordination produces a model that looks right but has not been tested against itself. You find out what it missed when the trades start installing things that do not fit together.

When you brief a BIM team, ask specifically about their coordination process. Not in general terms, specifically. How often does clash detection run? Who attends coordination meetings and who has authority to make design decisions in the room? How are issues logged? How do resolved issues flow back into the models? What happens when a clash requires input from someone outside the BIM team’s scope?

If the answers are vague, push for specifics. Vague coordination process in a brief becomes no coordination process in practice. You want to know exactly how this team runs coordination before you rely on it.

Deal With the Practical Stuff in Week One

Software versions, file formats, CDE platforms, naming conventions, template files, BIM standards documents. None of this is exciting. All of it matters more than people think until it causes a problem.

Ask these things early. Which version of Revit is the project running on? How does the BIM team access the CDE and what platform is it? Are there project templates or standards they need to work to? What file formats do deliverables need to arrive in? Are there naming conventions the client or contractor requires?

A model that arrives in the wrong format, built on the wrong template, named in a way that breaks the CDE structure, that model creates work for someone. Usually at a point in the project when nobody has spare capacity to deal with it.

Ten minutes of practical questions in week one. That is all it takes.

Define Handover Before the Project Starts, Not Before It Ends

This one genuinely baffles me every time I see it happen.

Handover requirements get defined in the last month of a project that has been running for two years. By that point, whatever the BIM team can do in the time remaining is the handover. Which is almost never what anyone actually needed.

Handover requirements need to be in the brief. What does a complete handover look like? Is it model files and exported drawings? Schedules and quantity data? An as-built model that reflects construction changes? A COBie export formatted for the FM system the client is running? Training for the facilities team so they can actually use what they receive?

Each of those things requires work that runs through the whole project. If the BIM team knows from day one that handover needs a fully populated FM-ready model with asset data attached to every element, they build toward that from the first week. If they find out a month before practical completion, they do their best. Their best in that situation is not the same as what the project needed.

Put handover in the brief. Be specific. Then the team can build toward it from the start.

The Honest Bottom Line

Briefing a BIM team well is not technically complicated. It does not require deep BIM knowledge. It just requires being specific about things that most people leave vague because vague feels easier in the moment.

Why the model exists. What LOD at each stage. Every discipline written down and scoped explicitly. Coordination separated from modeling and both defined clearly. Practical file and software questions sorted in week one. Handover defined before the work starts.

Do those things and the BIM team has everything they need to build what your project actually requires. Leave any of them out and the gaps become problems. Those problems have a habit of arriving when the project is under the most pressure and when fixing anything costs more than it ever should have.

Get the brief right. Honestly, everything else becomes easier because of it. Ready to find out what your project will cost? Find out here.