Most RFI-reduction advice focuses on processing RFIs faster \u2014 better logs, quicker turnaround, cleaner submittals. That’s workflow management. It doesn’t reduce RFI volume; it just handles the backlog more efficiently.<\/p>\n
This post is about something different: closing the drawing gaps that generate RFIs in the first place, before bid, before mobilization, before anyone touches the site. The distinction matters because an RFI resolved in the field is still a disruption \u2014 to the schedule, to the GC’s budget, to the subcontractor waiting on an answer. An issue caught during plan review is a redline on a PDF.<\/p>\n
The four steps below are a practical sequence for a pre-issue coordination review. They run on your 2D drawing set. No BIM required.<\/p>\n
High RFI counts are a symptom. The underlying condition is a drawing set that doesn’t fully agree with itself \u2014 sheets that contradict each other across disciplines, specs that call something different from what the drawing shows, coordination gaps where required elements simply aren’t on the sheet they belong on.<\/p>\n
What an RFI actually costs<\/a> breaks down the economics: every RFI consumes hours from the GC, the architect, and the engineer before anyone types a formal response. Multiply by a hundred RFIs on a mid-size project and you’re looking at a material schedule and cost impact before a single change order is written.<\/p>\n The projects with the lowest RFI volumes typically share one thing: the drawings were reviewed comprehensively, across disciplines and against the specs, before they were issued for construction. That’s the window this playbook targets.<\/p>\n The most expensive conflicts are the ones no single discipline’s reviewer would catch, because they’re distributed across two or more drawings that each look correct in isolation.<\/p>\n A shear wall and a duct main that occupy the same space don’t show up on the structural sheets as a problem, and they don’t show up on the mechanical sheets as a problem. They only show up as a problem when someone reads both sheets against each other \u2014 or when the crew in the field discovers they can’t build both at once. On one Flikt-reviewed project, a structural conflict of exactly this type carried an estimated $28,000\u2013$45,000 in rework plus 14\u201321 days of schedule impact<\/strong>. Caught in review, it’s a coordination note. Caught in the field, it’s a change order.<\/p>\n The coordination check should explicitly ask:<\/p>\n This isn’t a theoretical checklist \u2014 it’s the set of seam-points where the most expensive conflicts consistently hide. The Proceso de coordinaci\u00f3n de MEP<\/a> goes deeper on how these seam-points form and what a structured coordination workflow looks like.<\/p>\n Spatial conflicts get most of the attention, but some of the most RFI-productive problems in a drawing set are simply omissions<\/em> \u2014 something required that’s absent from the sheet it should appear on.<\/p>\n Spec-vs-drawing conflicts<\/strong> are a parallel category: the specification section and the drawing call different products, assemblies, ratings, or finishes. Neither is “wrong” on its own; they just disagree. The GC hits the discrepancy in the field, sends an RFI, and waits. Multiply by how many times a finish schedule, door schedule, or equipment spec drifts from what the drawing shows, and you have a predictable RFI queue.<\/p>\n Run this check against:<\/p>\n Missing-coordination gaps are the most insidious version of this: a fire-alarm device layout that was never extended onto the renovation addition; an ADA clearance that no sheet actually accounts for. These aren’t conflicts between two contradictory sheets \u2014 they’re an absence, and absence is harder to see.<\/p>\n A constructability review asks whether what the drawings show can actually be built as drawn \u2014 in the sequence, with the clearances, at the dimensions specified. It’s distinct from a coordination check (which asks whether the disciplines agree) and a code check (which asks whether the documents comply with standards). Constructability asks whether a real crew can execute the work as documented.<\/p>\n Common constructability issues that generate RFIs:<\/p>\n Constructability issues rarely appear in a single sheet. They show up when you read the structural sequence against the MEP rough-in against the architectural finishes. A revisi\u00f3n de constructibilidad<\/a> run at design development \u2014 before the documents are locked \u2014 is the highest-leverage point to catch them. A post-CD review still catches them before bid, which is still worth doing.<\/p>\n Manual review is good. The limitation is comprehensiveness: a senior reviewer working through a 600-sheet set on a deadline will catch the conflicts they know to look for, in the areas they focus on. They will miss things.<\/p>\n The case for automated review isn’t that it’s more insightful than an experienced reviewer \u2014 it’s that it’s more exhaustive<\/em>. It reads every sheet against every other sheet, every drawing callout against every spec section, without fatigue and without the time pressure that compresses a real review.<\/p>\n Flikt runs Plan de revisi\u00f3n de construcci\u00f3n con IA<\/a> directly on 2D PDF drawing sets and surfaces conflicts across four categories: spatial clashes, spec-vs-drawing mismatches, missing coordination, and code or clearance issues. On one real project, the review flagged more than 40 conflicts that eventually traced to change orders<\/strong> \u2014 conflicts distributed across architectural, structural, and MEP sheets, none visible from a single discipline’s drawings.<\/p>\n The benchmark Flikt tracks across projects is conflictos por cada 100 hojas<\/strong> \u2014 a normalized drawing-quality metric that lets you compare document quality across design teams, project types, and revision cycles, and measure whether a redline cycle actually improved the set. See conflictos por cada 100 hojas<\/a> for what that benchmark looks like in practice.<\/p>\n This step works best as a complement to Steps 1\u20133, not a replacement for them. Automated review catches what’s distributed and hard to see comprehensively. Manual coordination review catches what requires judgment about the building’s intent. Together, they close the gaps the other misses.<\/p>\n RFI volume per project is a lagging indicator \u2014 you only know it after the fact. Drawing quality measured before construction is a leading indicator you can act on.<\/p>\n Two metrics worth tracking at plan review:<\/p>\n Conflicts per 100 sheets<\/strong> \u2014 how many real, actionable conflicts the set contains, normalized by sheet count. Lower is better; trends over revision cycles tell you whether the coordination process is working.<\/p>\n RFIs per 100 sheets (post-construction)<\/strong> \u2014 how many RFIs the project generated during construction, normalized the same way. Over time, projects that go through rigorous pre-issue review should show meaningfully lower post-construction RFI rates.<\/p>\n Industry studies estimate that errors caught during construction cost roughly diez veces m\u00e1s para arreglar<\/strong> than the same errors caught during plan review. The goal of pre-construction QA is to shift that ratio \u2014 catch as many issues as possible on paper, where they cost a fraction of what they’ll cost in the field.<\/p>\n A structured approach to this is in the pre-construction QA checklist<\/a>, which organizes the full review sequence \u2014 from document receipt through final coordination sign-off \u2014 into a trackable format.<\/p>\n The four steps above aren’t a new discovery. Every experienced superintendent knows that RFIs cluster around coordination gaps. What changes when you run them systematically, before issue, on the full document set:<\/p>\n The economics are documented on la p\u00e1gina de evidencia<\/a>. If you want to quantify what catching conflicts earlier is worth on your specific project, the ROI calculator<\/a> runs the numbers.<\/p>\n For architects carrying coordination liability, what Flikt’s review means for your practice<\/a> covers how the workflow integrates with standard deliverable schedules and what the conflict documentation looks like.<\/p>\n Ready to see what’s hiding in your drawing set before the first RFI hits? Contact us<\/a> to review a project \u2014 no BIM, no modeling software, just your PDFs.<\/em><\/p>\n Sube tu conjunto de planos y obt\u00e9n detecci\u00f3n de conflictos con IA, no se requiere BIM.<\/p>\n Comenzar<\/a> Most RFI-reduction advice focuses on processing RFIs faster \u2014 better logs, quicker turnaround, cleaner submittals. That’s workflow management. It doesn’t reduce RFI volume; it just handles the backlog more efficiently. This post is about something different: closing the drawing gaps that generate RFIs in the first place, before bid, before mobilization, before anyone touches the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-516","post","type-post","status-publish","format-standard","hentry","category-blogging"],"yoast_head":"\n
\nStep 1: Run a cross-discipline coordination check<\/h2>\n
\n
\nStep 2: Run a completeness and spec-vs-drawing check<\/h2>\n
\n
\nStep 3: Do a constructability pass<\/h2>\n
\n
\nStep 4: Run automated conflict detection on the full 2D set<\/h2>\n
\nThe metric: what to measure before and after<\/h2>\n
\nPutting it together<\/h2>\n
\n
\n\u00bfListo para detectar conflictos a tiempo?<\/h3>\n
\n\ud83d\udcc5 Reservar una demostraci\u00f3n<\/a>\n<\/div>","protected":false},"excerpt":{"rendered":"