■ MEP BIM INSIGHTS — BIM GUIDES

How to Write a BIM RFP That Actually Gets You What You Need

A poorly written BIM RFP generates responses that cannot be compared. One team proposes LOD 300 coordination. Another proposes LOD 200 with LOD 400 available as an add-on. A third uses different terminology entirely. None of them are wrong — they are responding to an ambiguous document by making their own assumptions.

The result is a selection process where you are not comparing equivalent proposals, and the team you select may deliver something very different from what you expected.

This article covers what a BIM RFP for MEP modeling or coordination services must specify to generate comparable, evaluable responses — written from the perspective of a team that receives these RFPs regularly.


What Most BIM RFPs Get Wrong

The most common problem: the RFP describes the project but not the BIM scope. It tells the responding team what is being built but not what the BIM team is expected to produce, to what standard, in what format, and for what purpose.

This forces every responding team to make their own assumptions about scope — and experienced teams will price those assumptions conservatively. The result is either inflated proposals or proposals that later generate significant change orders when the actual scope is clarified.

The best BIM RFPs read like a draft BEP. They define deliverables, LOD, software, coordination process, and QA/QC requirements before asking for a price. Teams can then respond with a specific scope confirmation and a precise price — not a range based on assumed conditions.


The Five Things Every BIM RFP Must Specify

SECTION 01

Project scope and LOD matrix

Define exactly what disciplines are in scope and what LOD each must reach at each project phase. Do not write “full MEP BIM coordination at LOD 300.” Write a matrix:

  • Mechanical (HVAC): LOD 300 at CD, LOD 400 for mechanical room prefabrication
  • Plumbing: LOD 300 at CD
  • Electrical: LOD 300 at CD (conduit routing, panel schedules, equipment)
  • Fire Protection: LOD 300 at CD (design model, not fabrication)
  • Structural (for coordination reference): LOD 300 provided by structural engineer

Also specify the source files the BIM team will receive: 2D DWG from the design team, point cloud from an existing building, IFC from a structural engineer. Each source type has different preparation requirements and affects the scope estimate significantly.

SECTION 02

Software, file formats, and CDE platform

Specify:

  • Required authoring software and version (e.g., Autodesk Revit 2024)
  • Coordination software (Navisworks Manage, BIM 360/ACC, or both)
  • Required export formats (RVT, IFC2x3, IFC4, NWD, DWG, PDF)
  • Common Data Environment: BIM 360, ACC, Procore, ProjectWise, or shared server
  • File naming convention if you have a standard
  • Coordinate system: shared coordinates with the architectural model, or standalone

A team using Archicad or Vectorworks cannot deliver a native Revit model. A team without a BIM 360 subscription cannot participate in a BIM 360-based CDE workflow. These requirements filter respondents to teams that can actually perform the work.

SECTION 03

QA/QC and coordination requirements

Specify what the coordination process looks like, not just the output:

  • How many clash detection rounds are required before final model issue
  • Whether the BIM team is responsible for resolving clashes or only reporting them
  • Whether coordination review sessions (Zoom/Teams) are included and how frequently
  • What clash tolerance is acceptable (hard clashes: zero; clearance clashes: defined distance)
  • Whether a written clash resolution log is required at project closeout
  • Whether an internal QA/QC report is required before each model issue

These requirements directly affect the effort required and therefore the price. A team priced for “deliver the model” will not include the overhead for bi-weekly coordination sessions, clash resolution tracking, and formal QA/QC reporting unless those are specified.

SECTION 04

Standards and compliance requirements

For US projects, specify which standards apply to the engineering scope:

  • ASHRAE 90.1 edition (2019 or 2022) for energy compliance
  • ASHRAE 62.1 for ventilation
  • SMACNA for duct construction
  • NFPA 13 for fire protection
  • NEC edition for electrical
  • IBC edition and local amendments

If the project requires a COBie deliverable, specify this explicitly — including which worksheets are required and what FM system will receive the data. COBie preparation is a significant effort item that is frequently omitted from scope until project closeout.

For healthcare projects, specify ASHRAE 170 and FGI Guidelines applicability. For industrial projects, specify any process standards (ASME B31.1, B31.3) and hazardous area classification requirements.

SECTION 05

Evaluation criteria and required response format

Tell respondents exactly how you will evaluate proposals and what you need to see:

  • Team qualifications: list of comparable completed projects (building type, size, LOD, software)
  • Sample deliverable: a clash report or coordination model excerpt from a similar project
  • Proposed workflow: how will coordination sessions be structured, who is the point of contact, what is the revision process
  • Pricing: fixed fee by phase, or hourly with a not-to-exceed cap
  • Timeline: proposed milestone schedule keyed to the design team’s document issuance dates

Without a required response format, proposals arrive in incompatible structures and comparison becomes a matter of reading between the lines. A structured response format produces proposals you can compare in a table.


Red Flags in Proposals You Receive

Even with a well-written RFP, some proposals will be vague or misleading. Watch for:

  • “We will model to the required LOD” without specifying which LOD they understood from the RFP — they did not read it carefully or are hedging
  • No sample deliverables from comparable projects — they may not have done this type of work before
  • A single fixed price with no phase breakdown — no visibility into how scope changes will be priced
  • Vague coordination process description — “we will coordinate with all disciplines” without specifying how, how often, and who is responsible for resolution
  • No mention of US standards in a US project proposal — a team that does not reference ASHRAE, NFPA, or NEC in their response to a US MEP RFP has not worked on US projects

The Kickoff Call as Scope Verification

Even with a precise RFP, conduct a 30-minute kickoff call with shortlisted teams before selection. The purpose is not to evaluate presentation skills — it is to verify that the team understood the scope correctly and can answer specific technical questions about how they will execute it.

Ask: What Revit version will you use? How do you handle the coordination when the structural model is updated mid-process? What is your turnaround time for a model revision after a review session? How many hard clashes do you typically find and resolve on a project of this type?

The answers tell you more than the written proposal.

What We Include in Our Proposals

When GEOMETRY-S responds to a BIM RFP, we include a scope confirmation matrix that cross-references every requirement in the RFP against our proposed deliverable. If the RFP is ambiguous on a point, we state our assumption explicitly and flag it for discussion before contract execution.

We are happy to review draft BIM RFPs before issuance and advise on scope clarity — at no charge. A better-written RFP produces better proposals and a better engagement for both parties.