How to Build a BIM QA Workflow That Cuts RFIs

how to reduce RFIs with BIM

Every construction project generates RFIs. The question is whether those RFIs represent genuine design ambiguity that couldn’t be resolved until the project was underway, or documentation failures that a structured pre-construction process should have resolved before a single drawing went to the site. On most projects, the answer is the second one. Studies by the Construction Industry Institute consistently show that 60–70% of RFIs on commercial projects originate from coordination failures, missing information, and documentation errors that pre-construction BIM coordination should have caught. For a breakdown of which BIM services have the most direct impact on RFI volume.

The gap between projects that generate 200 RFIs and projects that generate 40 is rarely the complexity of the building. It’s whether the BIM team followed a structured quality assurance workflow or treated clash detection as a one-off exercise rather than a repeating discipline. see our guide on how BIM modeling services reduce RFIs.

Quick Answer

A BIM QA process is a structured and repetitive series of tasks for assessing the quality, compliance, and coordination of models at specified stages before the issuance of construction documents. There are five key steps involved in the process: model standard review, LOD compliance assessment, clash detection, coordination issue tracking and resolution, and pre-issuance QA gate. Done consistently, it eliminates the documentation failures that generate most RFIs.

Why Most BIM Workflows Still Generate Too Many RFIs

The problem isn’t usually that teams skip BIM. It’s that they treat BIM coordination as an event rather than a process. A clash detection run at design completion, a round of comments, a few revisions, and then documentation is issued. That approach catches the most obvious conflicts but misses the coordination failures that generate RFIs in the field.

Three patterns produce high RFI volumes on BIM-coordinated projects:

  • One-off clash detection: Running clash detection once, late in the design process, when major routing decisions can no longer be changed without high cost. Clashes get logged but are not resolved before the issue.
  • No issue tracking discipline: Clash reports produced but not formally assigned, tracked, and closed. The same clashes reappear in the next round of detection.
  • LOD misalignment: Structural and MEP models coordinated at different levels of detail, so clearance clashes, the ones that generate the most on-site RFIs, are invisible until fabrication.

A structured BIM QA workflow fixes all three. Here’s how it works.

The 5-Step BIM QA Workflow

STEP 1: Model Standards Check Before Coordination Begins

Before BIM coordination can work, every discipline model must meet agreed standards. This is not about the quality of visualization but whether the model is actually coordinateable. A model with conflicting grid references, incorrect heights between floors, or conflictual links will generate erroneous clash detections, which would defeat the entire purpose of the coordination process. Erroneous clashes that render the whole process meaningless.

The standards check covers:

  • Grid and level references confirmed consistent across all discipline models
  • File naming and model structure aligned with the agreed BIM Execution Plan
  • Linked file integrity: all referenced files resolved with no missing links
  • Model purging no unused families, views, or worksharing errors

This step takes 30–60 minutes per discipline model and prevents hours of false coordination work downstream.

STEP 2: LOD Compliance Review

Clash detection at LOD 300 catches geometric intersections. Clash detection at LOD 350 catches clearance clashes, insufficient space for insulation jackets, maintenance access, structural connections, and hanger brackets. Most on-site RFIs that relate to MEP coordination come from clearance clashes that were invisible at LOD 300. The LOD compliance review confirms every discipline model is at the required level of detail before coordination runs begin. For a detailed explanation of how LOD affects clash detection accuracy, see our guide on what clash detection is in BIM.

The LOD check is discipline-specific. Structural models typically need to reach LOD 350, including connections, embeds, and penetrations, before coordination with MEP makes sense. A coordinated model where the structure is at LOD 300 and MEP is at LOD 350, will systematically miss clearance conflicts.

STEP 3: Scheduled Clash Detection Cycles Not One-Off Runs

This is the step that separates low-RFI projects from high-RFI ones. Clash detection isn’t a single event at the end of design; it’s a recurring discipline that runs on a fixed schedule throughout design development. On a typical commercial project, weekly or fortnightly coordination cycles give each discipline time to respond to flagged clashes before the next run. Our BIM clash detection services operate on exactly this scheduled cycle rather than one-off event-based detection.

Each coordination cycle produces three outputs: a clash report showing all new conflicts, a comparison with the previous cycle showing which clashes were resolved, and a list of priority clashes requiring discipline lead response before the next cycle. Without this structured cycle, clash reports accumulate without resolution, and the same conflicts appear repeatedly.

On high-density projects, data centres, hospitals, or high-rise towers, clash detection cycles are often more frequent in the podium and plant room levels where MEP systems converge. For a detailed look at how this applies to high-rise projects specifically, see our article on why Dubai high-rise projects need BIM clash detection.

STEP 4: Coordination Issue Tracker and Resolution Protocol

A clash report is an input. A resolution is an output. The step that most teams skip is the structured process that turns one into the other. Every clash identified in Step 3 needs to be logged in an issue tracker assigned to a responsible discipline, given a resolution deadline, and formally closed when addressed. This is the core work of BIM coordination services, not producing the clash report, but managing the resolution cycle.

The issue tracker structure matters:

  • Clash ID: unique reference number for every logged conflict
  • Discipline responsible: who must respond to structural, MEP, and architectural
  • Status: Open, In Progress, Resolved, Closed
  • Resolution deadline: aligned to the next coordination cycle date
  • Resolution description: what was changed and in which model version

Without this structure, coordination meetings become conversations about problems with no accountable resolution. The issue tracker makes every open clash visible to every discipline, creates pressure for timely response, and provides a documented audit trail showing what was resolved and when.

STEP 5: Pre-Issue QA Gate Before Documentation Goes to Site

The final step in the QA workflow is a gate check before any construction documentation is issued. This isn’t another coordination cycle; it’s a structured sign-off confirming that all priority clashes from the tracker are closed, the model has been updated to reflect resolutions, and the documentation extracted from the model is complete and consistent.

The pre-issue gate check covers:

  • All Priority 1 clashes marked Closed in the issue tracker
  • Model revision confirmed resolutions implemented in live model files
  • Shop drawing extraction run from the updated model, not from superseded versions
  • Drawing set cross-referenced sheet numbers, revision marks, and title block information consistently
  • Discipline leads sign-off, formal confirmation that each discipline model is construction-ready

This gate check is what prevents documentation failures from reaching the site. It’s the mechanism that keeps RFI volume low throughout construction. For more context on how model-derived documentation reduces rework alongside RFIs, see our analysis of how BIM modeling reduces rework on construction projects.

Tools That Support Each Step

Workflow Step Primary Tool What It Does in QA
Model standards check Revit + Dynamo scripts Automated checks on naming, grid alignment, and link integrity
LOD compliance review BIM Track / Solibri LOD validation against BIM Execution Plan requirements
Clash detection cycles Autodesk Navisworks / Solibri Federated model clash detection with discipline filtering
Issue tracker BIM 360 Issues / Plannerly / Excel Clash logging, assignment, status tracking, and closure
Pre-issue QA gate Navisworks + manual checklist Final model validation and documentation extraction review

Need a Structured BIM QA and Coordination Workflow?

Optimar Precon provides BIM coordination services with structured weekly clash detection cycles, issue tracking, and pre-issue QA gate checks for commercial, industrial, and high-rise projects across the USA, UK, UAE, and Ireland. Contact us to discuss your project coordination requirements.

The RFIs You’re Still Getting Are Coming From the Steps You Skipped

Every construction project that runs a BIM workflow cuts some RFIs. Projects that run a structured BIM QA workflow with all five steps, on a consistent schedule, cut most of them. The difference is process discipline, not software. Navisworks and Solibri can detect every clash in a federated model. They can’t ensure those clashes get resolved, tracked, and closed before documentation is issued. This is what the workflow does.

Teams that adopt BIM coordination as a process and not an event always generate fewer RFIs, a better construction schedule, and no subcontractor conflicts. The five steps above are not complex. They are simply the steps that most projects skip. Contact us to discuss how a structured BIM coordination workflow can support your next project.

FAQs

How often should clash detection run in a BIM QA workflow?

On most commercial projects, weekly during active design coordination and fortnightly during design development. The frequency should match how often each discipline team updates its model. Running clash detection before teams issue meaningful model updates creates redundant results, while delaying detection allows unresolved clashes to accumulate.

Who is responsible for running BIM QA on a project?

The BIM coordinator is typically appointed by the main contractor or the employer’s agent, depending on the contract structure. On projects following ISO 19650, the information manager is formally responsible for the QA workflow. In practice, the person running weekly coordination cycles and managing the issue tracker is the effective QA owner regardless of title.

What’s the difference between a clash detection report and a BIM QA workflow?

A clash detection report is a single output, a list of conflicts found at a point in time. A BIM QA workflow is a repeating process that uses clash detection reports as one input, alongside model standards checks, LOD reviews, issue tracking, and pre-issue gates. The report tells you what’s wrong. The workflow is the process that ensures it gets fixed.

Can this workflow be managed by an offshore BIM team?

The offshore BIM coordination teams can coordinate the entire workflow cycle remotely, conducting coordination cycles according to schedule, updating the issue tracker, and providing pre-issue gate reports. The key requirement is structured communication and clearly defined handover points between the offshore team and the discipline leads. For guidance on selecting a provider capable of running structured coordination workflows, see our guide on how to choose a BIM modeling service provider.

What does a low-RFI project look like compared to a high-RFI one?

Low-RFI projects have two things in common: they ran weekly coordination cycles from early design development, and they maintained a live issue tracker with discipline sign-off at every cycle. High-RFI projects either skipped coordination until late in the design process, ran one-off clash detection without issue tracking, or issued documentation from uncoordinated models. The documentation failures that reach the site and become RFIs are always traceable back to one of these three root causes.

Scroll to Top