Datacenter
BIM and VDC coordination and clash detection field guide
Build the job in a federated model first, find and resolve the clashes in coordination before the field finds them, and push the coordinated model to prefab, layout, and install.
Direct answer
BIM coordination is the practice of building a project in a federated 3D model before the field does, so the conflicts get found and resolved in the model instead of in the wall. Clash detection software flags where systems collide, and the team fixes them in coordination meetings. The BIM execution plan and project standards govern the work.
Key takeaways
- BIM coordination builds the job in one federated 3D model so clashes are found and resolved before the field hits them.
- A hard clash is two solids in the same space; a soft clash is too little clearance for access, insulation, or a valve handle.
- Multi-trade coordination needs at least LOD 350 (connections); push to LOD 400 for fabrication, and 500 is verified as-built.
- Clash priority order: structure wins, then gravity drainage, then large duct and mains, then smaller pipe, tray, busway, and last conduit and wire.
- A zone is coordinated only when open clashes hit zero or a documented set of accepted exceptions, gating fabrication release.
BIM coordination, and why the model finds the clash first
BIM coordination is the work of building the project virtually, in one combined 3D model, before anyone builds it for real. Each trade models its own scope. Structural models the steel and concrete, mechanical models the duct and equipment, electrical models the conduit, cable tray, and gear, plumbing models the pipe, and fire protection models the sprinkler mains and branch lines. Those models get combined into a single federated whole, and software checks where one trade's geometry runs into another's.
The payoff is clash detection. When the duct runs through a beam, when a 6 in chilled water pipe crosses a cable tray, when a sprinkler main lands where the busway is supposed to go, the model shows it. The team resolves it in a coordination meeting, on the screen, weeks before the material is on site. That is the whole point. You move a line in the model in ten minutes instead of cutting out installed pipe in the field for a day.
VDC, virtual design and construction, is the broader process this lives inside: model, coordinate, then use the coordinated model to drive prefab, field layout, and install. This guide covers the coordination and clash-detection core. The open questions that surface during coordination usually become RFIs, and the model eventually feeds the commissioning and handover record, so the RFI-submittal and commissioning guides are the siblings to read alongside it.
Why find the clash in the model and not the field?
The conflict that costs you almost nothing in the model costs many times more once it is built. A clash caught in coordination is a few minutes of someone dragging a duct down 4 in. The same clash caught in the field is a stopped crew, a cut-out section, a refabricated spool, an RFI to the engineer, and a hole in the schedule. The rule of thumb the trade repeats is roughly ten to one, and the order of magnitude is right even if the exact multiple is not.
That is the hook for the entire discipline. Find and resolve the conflicts in the model, in a meeting, before the field finds them in the wall. Everything else, the federated model, the clash rules, the coordination cadence, the priority order, exists to serve that one outcome.
Data centers make the case better than any other building. The ceilings are packed with large duct, multiple chilled water and condenser water mains, dense cable tray and busway, and fire protection, all fighting for the same plenum above a hard ceiling height the design cannot give up. There is no slack to absorb a missed clash in the field. On that kind of build, coordination is not a nicety. It is how the job gets installed at all.
What are BIM and VDC?
BIM, building information modeling, is the model: a 3D representation of the building where each element carries data, not just lines. A pipe in the model knows its size, material, system, and elevation. A piece of gear knows its make, its weight, its clearances. That data is what separates a BIM model from a 3D picture.
VDC, virtual design and construction, is the process of using that model to plan and build the work. BIM is the noun, VDC is the verb. You author the models, federate them, run clash detection, coordinate, and then take the coordinated result out to the shop and the field.
The difference from 2D drawings is that the model carries the third dimension the drawings only imply. On a plan and a section, a duct and a pipe can both look fine in their own views and still occupy the same cubic foot of space, because no one cross-checked every view against every other. The model checks all of it at once. That is why coordination moved off the light table and into the model. The exact tools, model uses, and scope are set by the BIM execution plan and the project standards, which vary by team and contract.
The federated model
The federated model is the single coordinated whole, assembled from every trade's individual model. It is the thing clash detection runs against, and it is the closest the project gets to seeing the finished building before it exists.
Federation does not mean merging the models into one file that everyone edits. Each trade keeps authoring in its own native model. The coordination platform references those models and overlays them in a shared space, so structural stays structural, mechanical stays mechanical, and the combined view shows them together against one common origin. Each team keeps control of its own scope and republishes its model on the coordination schedule.
The federated model is only as good as the models feeding it. A trade that has not modeled its hangers and supports, or that modeled to a loose level of development, will show clear in coordination and then clash in the field where the steel it never drew actually lands. Hangers, supports, access space, and valve handles are where the late surprises hide. The federation is honest only when every contributing model is complete to the level of development the BIM execution plan called for.
What is clash detection?
Clash detection is the automated check that finds where elements from different models occupy the same space or violate a clearance rule. Coordination software of the Navisworks type, and the cloud model-coordination platforms, run the federated model against clash tests and produce a clash report listing every conflict, where it is, and which two systems are involved.
There are two kinds that matter. A hard clash is two solid things in the same space: a pipe straight through a beam, a duct through a wall opening that does not exist. A soft clash, also called a clearance clash, is two things too close together even though they do not physically touch. A valve with no room to turn its handle. A cable tray with no space to lay in cable. A unit with no clearance to pull a filter or open a panel. Soft clashes are the ones crews underrate, because the model looks clean while the install is impossible.
The first clash run on a real project returns hundreds or thousands of hits, and most of them are noise: the same duct touching the same wall fifty times, two parts of the same system that are supposed to connect. The skill is filtering the noise from the real conflicts using clash rules, search sets, and grouping, all set up to match the BIM execution plan. A raw clash count is not progress. Resolved, closed clashes are.
The coordination meeting
The coordination meeting is where the clashes get resolved. The BIM manager or VDC lead runs it, the trades sit at the table with their models, and the group walks the open clashes one by one. For each one, the question is simple: who moves, and to where. The answer gets assigned to a trade, with a due date, and it gets tracked until the model is updated and the clash closes.
The cadence is usually weekly during active coordination, often working zone by zone and level by level rather than the whole building at once. A typical rhythm is publish models by a set day, the BIM manager federates and runs clashes, the team reviews the grouped report in the meeting, and each trade goes back, makes the moves, and republishes for the next cycle. Pull the schedule forward in the zones that install first.
Tracking to closure is the part that separates real coordination from a meeting that produces a list and nothing else. A clash that is reviewed, discussed, and assigned but never actually resolved in the model is still a field conflict. The discipline is closing every assigned clash before that zone is signed off and released for fabrication. Sign-off is the gate: a zone is coordinated when the open-clash count in that zone is driven to zero or to an agreed, documented set of accepted exceptions.
Who moves when two trades clash?
When two systems fight for the same space, the one that is hardest and most expensive to move stays, and the flexible one bends around it. That priority order is what keeps coordination meetings from turning into a standoff, and most teams write it into the BIM execution plan as a clash matrix or hierarchy of systems.
The usual order, roughly: structure wins, because steel and concrete do not move for anyone. Gravity systems come next, sanitary and storm drainage and condensate, because they have to keep their slope and cannot just be rerouted up and over. Large-bore ducts and big pipe mains are next, since they are bulky and have limited room to shift. Then smaller pipe, then cable tray and busway, and last the small, flexible stuff: branch conduit and wire, which can route around almost anything.
The order is a starting point, not a verdict. A small conduit that has to hit a specific panel may have less freedom than its size suggests, and a gravity line near its invert may have no give at all. The trades negotiate the real move in the room, against the hierarchy, the available space, and the install sequence. What the priority order prevents is the argument restarting from zero on every clash. The project's matrix governs.
What is a BIM execution plan?
The BIM execution plan, the BEP, is the agreement that says who models what, to what level of development, on what schedule, and to what standards. It is the document that makes coordination possible, and a project that skips it coordinates by argument instead of by plan.
A working BEP nails down the model element matrix: which trade owns which systems and to what LOD at each stage. It sets the coordination zones and the meeting cadence, the model publishing schedule, the file naming and the folder structure, the shared coordinate origin and units, the clash matrix and clash tolerances, and the common data environment everyone works in. It also states the deliverables: what gets handed over, in what format, at the end.
Under ISO 19650, the BEP carries specific weight and is produced at defined points in the appointment, and the AIA documents frame it through a model protocol and the responsibility for each model element. The exact form and the named standard depend on the project and the team. What does not change is the need for the agreement to exist before models start colliding. No BEP, and the first hard problem becomes a fight over who was supposed to model the thing that clashed.
What is LOD in BIM?
LOD, level of development, describes how detailed and how reliable a model element is at a given stage. It tells a coordinator how much to trust what they are looking at. An element drawn loosely as a placeholder cannot be coordinated the same way as one modeled to fabrication detail, and treating the two the same is how false confidence gets into a job.
The common scale, as set out by the AIA documents and extended by the BIMForum specification, runs in six steps. LOD 100 is conceptual, a symbol or a mass. LOD 200 is generic, approximate size and location. LOD 300 is accurate geometry, specific size and position. LOD 350 adds the connections and interfaces between systems, which is the level real multi-trade coordination needs. LOD 400 is fabrication-level, detailed enough to build the spool or the assembly from. LOD 500 is the as-built, verified against what was actually installed.
Coordinate at the right level. Run hard clash detection on models that are only LOD 200 and you generate noise, because the geometry is not real yet. Push to sign-off and fabrication on LOD 350 to 400, where the model carries connections and real sizes. The LOD required for each element at each milestone is set in the BEP, and a related idea, the level of information that travels with the geometry, the manufacturer and the data, matters as much downstream for handover.
The common data environment
The common data environment, the CDE, is the single shared place where the models and the project data live, so everyone is working from the current version instead of a copy that went stale last Tuesday. On modern jobs it is a cloud platform, and the BEP names which one and how it is structured.
Version control is the reason it matters. Coordination falls apart the moment two trades are looking at different vintages of the same model. The electrical team moves conduit to clear a duct that the mechanical team already relocated three days ago, and now both are wrong. A CDE with a clear publish cadence and a status on every model, work in progress, shared, published, keeps the federated model honest and keeps the meeting arguing about real clashes instead of phantom ones.
ISO 19650 builds its whole information-management approach around the CDE concept and the states a model moves through. The specific platform and folder structure are a project choice. The principle holds regardless: one source of truth, current for everyone, or the coordination is built on sand.
The standards behind coordination
Coordination runs on agreed standards, because models from different companies, authored in different software, only combine cleanly when everyone followed the same rules. The two reference frames most projects point to are the AIA digital practice documents, common in the United States, and ISO 19650, the international information-management standard. The project picks the framework and writes the specifics into the BEP.
The specifics that have to match are unglamorous and decisive: the file naming convention so models sort and identify cleanly, the shared coordinate system and origin so models line up, the units, the LOD definitions everyone is measuring against, and the model element responsibility, who owns what. Get these agreed up front and federation is mechanical. Leave them to chance and the first combined model is a mess of misaligned, misnamed files nobody can clash.
Cite the framework the project actually adopted, and let the BEP and the contract documents control the detail. The standards give the structure. The BEP fills in the project-specific values, and where the two differ, the project documents win.
The coordinated model in the field
Coordination is not finished when the clashes close. The coordinated model is the source for how the building actually gets built, and a project that resolves every clash and then hands the field a set of 2D drawings has thrown away most of the value. The model is meant to be built from, not just drawn.
Three things flow out of the coordinated model. Prefabrication takes the model-accurate geometry and turns it into spools, racks, and modules built in a shop. Field layout takes points out of the model to a robotic total station or GPS rover, so the hangers, sleeves, and equipment pads get marked exactly where the coordinated model put them. Install crews carry the model on tablets, working from the same coordinated 3D the office signed off, instead of guessing from flat sheets.
This is where the discipline pays for itself, and it only works if the upstream work was honest. Spool off a model that was coordinated to LOD 400, lay out from a model on the verified origin, and the parts fit when they reach the field. Cut corners on the model and every one of those downstream steps inherits the error and ships it to site.
Prefab and spooling off the model
Prefabrication is the strongest reason MEP trades model to fabrication detail. A coordinated model carried to LOD 400 produces spool drawings, cut lists, and rack layouts directly, so the pipe gets cut, the duct gets formed, and the MEP racks get assembled in a shop under controlled conditions instead of overhead on a lift.
The model has to be fabrication-level for this to be real. A spool generated off LOD 300 geometry that never resolved its connections will not fit, and the shop finds out after it has built it. The strongest results come when the spool logic, rack standardization, transport and rigging limits, access constraints, and the install sequence are all worked out in the model before fabrication starts, with the model acting as the shared plan between design, the shop, and the field.
On a data center, prefab is how the schedule gets hit at all. Multi-trade overhead racks, mechanical skids, and electrical rooms get built as modules and set in place, which only works because the coordinated model proved they fit and the spools came straight off it. The coordination is what makes the prefab trustworthy enough to commit to.
Layout from the model to the total station
Field layout closes the loop between the coordinated model and the slab. Points exported from the model, the locations of sleeves, hangers, anchors, equipment pads, and wall lines, go to a robotic total station or a GPS rover, which then guides the crew to mark each point on the deck within a small tolerance, far tighter and faster than tape and string.
Because the layout points come from the coordinated model and the model is on the verified shared origin, the field gets built to exactly what coordination resolved. The same instrument can run in reverse to verify installed work against the model, catching a hanger or a sleeve that drifted before it becomes a clash with the trade that follows.
Layout is its own discipline with its own setup, control points, and instrument workflow, and the cross-link there is worth following. The point for coordination is that the model is not the end of the process. It is the input to the layout that puts the work in the right place the first time.
4D and 5D: the model plus schedule and cost
4D adds the schedule to the model. Tie model elements to schedule activities and you can play the build forward in time, see the sequence and the phasing, and catch a conflict in the plan, the crews stacked in one zone, the gear set after the wall it has to pass through is closed, before it happens on site.
5D adds cost. Quantities pulled from the model feed estimating and cost tracking, so a design change shows its quantity and cost impact instead of being a guess. The model becomes the source for how much of everything there is.
Both depend on a model that is accurate and well structured, and both are scoped in the BEP rather than assumed. Plenty of strong coordination jobs run mostly in 3D and add 4D for the install-sequence-critical zones. Use them where the planning payoff is real, not as a checkbox.
The as-built and record model
The as-built model, sometimes called the record model, is the coordinated model updated to reflect what was actually installed. Field changes, the duct that got rerouted around a surprise, the gear that landed an inch off, get captured so the final model matches the building rather than the plan.
This is the LOD 500 idea: geometry verified against the field. The record model is only worth what the field reporting behind it is worth, so the as-built has to be maintained as the work proceeds, not reconstructed from memory at closeout. A record model assembled in a panic the week before handover tends to document the design, not the building.
The reason to care is what comes next. The record model is the starting point for the owner's facility model and the handover, so its accuracy is the difference between a useful turnover and a folder of files nobody trusts.
The digital twin and handover
Handover is where the model leaves construction and goes to the owner for operations and maintenance. The as-built model plus the equipment data, the asset model, becomes the facility's record: where every piece of gear is, what it is, and the information the operators need to run and maintain it. When that model is kept live and connected to building data, it is what people mean by a digital twin.
The value is downstream and long-term. An operator who can find a valve, a damper, or a panel in the model, with its data attached, troubleshoots and maintains the building faster than one working from a drawing set and a binder. For a data center, where uptime is the whole product, the quality of that handover model is not a paperwork detail.
Handover ties directly to commissioning, which generates much of the equipment data and the verification record the owner receives, so the commissioning guide is the sibling to read for how that information gets produced and proven. What the owner ultimately receives, the format, the data fields, the level of information, is set by the owner's requirements and the BEP, agreed at the start rather than scrambled at the end.
Coordination is a people and process problem
The hardest part of coordination is not the software. It is the people and the process. The model finds the clashes, but only the trades can resolve them, and that takes every trade committing to model their scope, to the right LOD, on schedule, and showing up to the meetings ready to move their lines. One trade that does not engage breaks coordination for everyone, because the federated model is incomplete and the clashes against that trade never get found until the field finds them.
The BIM manager or VDC lead drives it, and the role is as much project management as it is technical. Chasing late models, holding trades to the publish schedule, running the meeting so it produces assigned, dated resolutions instead of discussion, and tracking every clash to closure. The software is doing the easy part. The discipline is human.
Treat coordination as a software deliverable and it fails quietly. Treat it as a commitment the whole team signed up for in the BEP, with someone given the authority to hold the line on the schedule and the closeouts, and it works. The buy-in has to be real, from the trades and from the people who can make a trade show up.
Garbage in, garbage out: model quality
Coordination is only as good as the models going into it. A late model, a model at the wrong LOD, a model on the wrong origin, or a model that does not reflect the real design intent corrupts the whole federation, and the clash report built on it is confidently wrong. Garbage in, garbage out is the oldest rule in the discipline and the one most often ignored under schedule pressure.
The defense is model quality control before federation. Confirm each model is on the shared origin, named to the standard, complete to the required LOD, and current. A quick QA pass on incoming models catches the missing hangers, the placeholder geometry someone forgot to develop, and the file that never moved off the old datum, before they pollute the clash run and waste a meeting.
The trap is trusting a clean-looking clash report from dirty models. Few clashes can mean great coordination or it can mean half the trades modeled nothing yet. Knowing which one you are looking at is the BIM manager's job, and it comes from QA on the inputs, not from the count on the output.
Where does BIM coordination pay off?
Coordination pays off most on dense, complex, tightly coordinated buildings, and it pays off least on simple ones. The value is fewer field conflicts, fewer RFIs born of clashes the drawings hid, less rework, faster and more certain install, and the prefab and schedule gains that ride on a trustworthy model. On the right job those add up to real money and real schedule.
The buildings where it pays the most are the ones with packed ceilings and tight tolerances: data centers first, then hospitals, labs, and central plants. Anywhere multiple large systems compete for the same plenum above a hard ceiling, coordination is what lets the work get installed without tearing it back out. Data centers are the most BIM-intensive builds for exactly this reason, plus the schedule pressure and the prefab volume that make a coordinated model non-negotiable.
On a simple, low-density building, heavy coordination can cost more than it returns, and the honest call is to scale the effort to the complexity. The clash that becomes an RFI is the link to the RFI-submittal sibling: good coordination cuts the conflict-driven RFIs that otherwise pile into the log and stall the schedule. Scope the coordination effort in the BEP to match what the building actually needs.
What to document
The coordination record is what proves a zone was coordinated and what answers the question later when the field hits something. It also protects the team: a clash that was raised, assigned, and closed in the record is a different conversation than one nobody can show was ever addressed.
Capture the model element responsibility and the LOD per stage from the BEP, the shared origin and coordinate setup, the model publish log, the clash reports and their resolution status, the meeting minutes with assignments and due dates, the zone sign-offs, and the model versions released to fabrication. Tie each closed clash to who resolved it and in which model version.
| Item | Requirement | Note |
|---|---|---|
| BIM execution plan | Who models what, to what LOD, on what schedule | The agreement that governs all coordination |
| Model element matrix | Trade responsibility and LOD per stage | Settles who owns the thing that clashed |
| Shared coordinate origin | One verified survey point, all models on it | Confirm on every model that joins |
| Model publish log | Version and date per trade per cycle | Proves everyone was on the current model |
| Clash reports | Open and closed, grouped, with status | Closed count is the progress, not raw count |
| Coordination minutes | Assignments, who moves, due dates | Turns the meeting into tracked actions |
| Zone sign-off | Open clashes driven to zero or agreed exceptions | The gate before fabrication release |
| Released model versions | Which version went to fab and layout | Ties the field result to a specific model |
Common mistakes
- Starting coordination with no BIM execution plan, so no one agreed who models what or to what LOD.
- Models on different origins, so they do not line up and the clash report is meaningless.
- Late or low-quality models that leave the federated model incomplete and the clashes unfound.
- Flagging clashes but never resolving them to closure, so they reappear as field conflicts.
- Coordinating at too low an LOD, generating noise instead of real, resolvable conflicts.
- Building from 2D and never using the coordinated model in the field for prefab, layout, or install.
- Trusting a clean clash report from dirty inputs instead of running QA on the models first.
- Treating coordination as a software task instead of a commitment the trades have to keep.
Field checklist
Want this checklist to run itself on every job — with photo proof and a signed record crews can hand the customer? That's FieldOS.
Standards and references
The framework lives in two places most projects point to. The AIA digital practice documents, including the model protocol exhibit and the responsibility for each model element, are common in the United States and are where the LOD concept was first formalized. ISO 19650 is the international standard for managing information across the project, and it frames the BEP, the common data environment, and the states a model passes through.
LOD definitions in common use trace to the AIA documents and the BIMForum LOD specification, which extended the scale to include 350 and described each level element by element. Coordination platforms of the Navisworks type, and the cloud model-coordination tools, run the clash detection and host the federated model. The clash matrix, the tolerances, the LOD per milestone, the file naming, the shared origin, and the deliverables are all set in the project BIM execution plan.
Cite the framework the project actually adopted, and let the BEP and the contract documents control the specifics. Standards and editions change, and the right value for any given project is the one its own documents set. Find and resolve the clashes in the model before the field does, run it to a BEP with shared coordinates and the right LOD, and push the coordinated model out to prefab, layout, and install. The rest is detail the project defines.
Units and terms
BIM coordination carries its own vocabulary, and the same idea shows up under different names across a BEP, a software interface, and a spec.
The terms below are the ones that have to be understood the same way by everyone at the table, because a disagreement about what LOD 350 means, or whose origin is the real one, is a disagreement that ends up in the field.
- BIM vs VDC
- BIM is the information-rich 3D model; VDC is the process of using that model to plan, coordinate, and build the work
- Federated model
- The combined model that overlays every trade's model in one shared space for clash detection, without merging the source files
- Hard clash
- Two solid elements occupying the same physical space, such as a pipe through a beam
- Soft clash
- A clearance violation where elements are too close, leaving no access, insulation, or service room, even though they do not touch
- BEP
- BIM execution plan: the agreement on who models what, to what LOD, on what schedule, and to what standards
- LOD
- Level of development: how detailed and reliable an element is, on a common scale of 100 concept, 200 generic, 300 accurate, 350 with connections, 400 fabrication, 500 as-built
- CDE
- Common data environment: the single cloud source of truth for the models and data, with version control so everyone is on the current model
- Shared coordinate origin
- The one survey point and coordinate system every model references, so the models line up when federated
- 4D / 5D
- 4D ties the model to the construction schedule for sequencing; 5D ties it to quantities and cost
FAQ
What is BIM coordination?
BIM coordination is building a project in a combined 3D model before construction, so conflicts between trades are found and resolved in the model rather than the field. Each trade models its scope, the models federate into one, and software flags every clash for the team to resolve in coordination meetings before fabrication and install.
What is clash detection in BIM?
Clash detection is the automated check that finds where elements from different models occupy the same space or violate a clearance. Software of the Navisworks type runs the federated model and reports every conflict. A hard clash is two solids overlapping; a soft clash is too little clearance for access, insulation, or service.
What is the difference between a hard clash and a soft clash?
A hard clash is two solid elements physically occupying the same space, like a duct through a beam. A soft clash, or clearance clash, is two elements too close together, leaving no room for access, insulation, or a valve handle, even though they do not touch. Soft clashes are the ones crews most often underrate.
What is a BIM execution plan?
A BIM execution plan, or BEP, is the agreement that sets who models what, to what level of development, on what schedule, and to what standards. It defines the coordination zones, the meeting cadence, the shared origin, the file naming, the clash matrix, and the deliverables. Under ISO 19650 it carries defined points and purposes.
What is LOD in BIM?
LOD, level of development, describes how detailed and reliable a model element is. The common scale runs 100 conceptual, 200 generic, 300 accurate geometry, 350 with connections, 400 fabrication-ready, and 500 verified as-built. Multi-trade coordination needs at least LOD 350, and the required level per stage is set in the BEP.
Who moves when two trades clash in coordination?
The system hardest to move stays, and the flexible one bends. The usual order is structure first, then gravity drainage that needs its slope, then large duct and pipe mains, then smaller pipe, cable tray, and busway, and last small conduit and wire. The project clash matrix in the BEP sets the real priority.
Why does BIM coordination matter most on data centers?
Data centers pack large duct, multiple chilled and condenser water mains, dense cable tray and busway, and fire protection into a tight plenum above a hard ceiling height. There is no field slack to absorb a missed clash, and the prefab and schedule pressure are high, so coordinating the model before install is how the job gets built at all.
What is a common data environment in BIM?
A common data environment, or CDE, is the single shared cloud location where the project models and data live, with version control so everyone works from the current model. It prevents coordination from breaking when two trades reference different vintages of the same model. ISO 19650 builds its information-management approach around the CDE concept.
How does the coordinated model get used in the field?
The coordinated model drives three things: prefabrication of spools, racks, and modules off model-accurate geometry; field layout, where points export to a robotic total station or GPS to place hangers and sleeves exactly; and install from the model on tablets. The model is meant to be built from, not just used to resolve clashes.
Why do BIM coordination efforts fail?
Coordination usually fails on people and process, not software. The common causes are no BEP, models on different origins, late or low-quality models, clashes flagged but never closed, coordinating at too low an LOD, and never using the coordinated model in the field. Trades must commit, model on time, show up, and resolve to closure.
People also ask
Codes cited in this guide
This guide is written and reviewed against the published standards below. Always confirm the current adopted edition with the authority having jurisdiction.