Engineering and architecture
What causes RFIs? Reading root causes from your own logs
By SourceX Editorial · Updated
Short answer
The common causes of RFIs fall into five groups: coordination conflicts, missing information, product substitutions, field conditions, and clarification of information already in the documents. To find your firm's own pattern, tag a sample of about 100 closed RFIs by cause, discipline and phase, then read the clusters, rather than leaning on borrowed industry averages.
Key takeaways
- Tag each RFI with one primary cause, and decide it from the official response, not from how the question was worded.
- Around 100 closed RFIs from several recent, similar projects give a workable first read without a full audit.
- Clarification RFIs point to how documents are presented, coordination RFIs point to the review process, and field condition RFIs often involve no design error at all.
- Cause tags become far more useful once each RFI is linked to its outcome: no change, a revised drawing or a change order.
- A tagged RFI log is a better operational record because it shows question, cause, answer and consequence in one place.
What are the common causes of RFIs?#
The common causes of RFIs are coordination conflicts between disciplines, missing or incomplete information, product substitutions, field conditions that differ from the documents, and requests to clarify something the documents already say. Almost every RFI fits one of these five groups, though some touch two.
The groups matter because each leads to a different fix. A conflict between structural framing and ductwork calls for a better interdisciplinary review. A clarification RFI about a detail that was on the drawings calls for clearer sheets or a better preconstruction walkthrough. Lumping both together as design errors hides the real lesson in each.
| Cause | What the RFI usually says | Where the fix usually sits |
|---|---|---|
| Coordination conflict | Two disciplines show different things in the same place | Interdisciplinary review, model coordination, sheet cross-references |
| Missing or incomplete information | A dimension, detail, spec section or schedule entry is absent | QA/QC checklists, detail libraries, fee and schedule pressure at issue |
| Product substitution | The contractor proposes an alternate, or the specified product is unavailable | Specification writing, basis-of-design clarity, substitution procedures |
| Field condition | Existing conditions differ from what the documents assumed | Existing conditions investigation, survey scope, allowances |
| Clarification | The answer is already in the documents but was hard to find or read | Sheet organization, general notes, contractor onboarding |
How to tag 100 RFIs without a research project#
Tagging 100 RFIs takes a spreadsheet, a fixed tag list and one or two reviewers who know the work. Pull closed RFIs from several projects of a similar type, so one troubled job does not dominate the result.
Archive exports are not always the best source for tagging. Procore's Extracts documentation says most items download as PDFs, while documents and photos keep their original file type. That suits record keeping but not analysis, so pull the RFI log as a list or report for tagging and keep the archive for reference.
- Step 1: choose recently closed projects that represent your main project types and delivery methods.
- Step 2: export each RFI log with number, dates raised and answered, subject, question, response, discipline and any cost or schedule flag.
- Step 3: read the question and the official response, then assign one primary cause from the five groups and an optional secondary cause.
- Step 4: add the discipline, the phase when the RFI was raised, and the sheet or spec section involved.
- Step 5: record the outcome: no change, a revised drawing or detail, or a change order.
- Step 6: have a second reviewer tag a slice of the same RFIs and compare; disagreements show where definitions need tightening.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Tagging rules that keep the exercise honest#
Tagging rules keep reviewers from turning root cause work into a blame session. The most important rule is to tag by the answer: if the response points to an existing detail, the RFI is a clarification, however strongly the contractor worded the question.
Keep the tag list short. Five causes plus owner change and duplicate are enough for a first pass; more categories spread the sample too thin to read.
| Ambiguous case | Tag it as |
|---|---|
| The response cites an existing sheet or spec section | Clarification |
| The response issues a new or revised detail | Missing information, or coordination if two disciplines disagreed |
| The owner changed scope and the RFI records it | Owner change, kept out of design quality counts |
| The contractor asks to use a different product | Product substitution, even if the specified item was discontinued |
| Demolition exposes hidden framing or utilities | Field condition |
| The RFI repeats an earlier one | Duplicate, linked to the original number |
Reading the results by discipline and phase#
Reading the results means looking for clusters, not ranking people. Group the tagged RFIs by cause and discipline, then by when they were raised. A cluster of coordination RFIs between structural and mechanical early in construction says something different from a steady trickle of clarification RFIs across every trade.
Compare the clusters with what the firm already believes. If principals assume most RFIs are contractors fishing for change orders, and the tags show missing-information items concentrated in one sheet type, the QA/QC lead now has a specific place to start. If field condition RFIs dominate renovation work, the fix may sit in the scope of existing conditions investigation, which is a fee conversation with clients.
Resist turning the sample into a benchmark. The point is to compare your own projects over time and to test whether a process change moved the pattern, not to claim a rate against other firms.
Illustrative: a structural and MEP firm tags its logs#
Illustrative: a fictional structural and MEP engineering firm pulls closed RFIs from five recent projects, a mix of new office buildings and school renovations, using its Procore records and Bluebeam markups. The COO and a senior project manager tag each RFI against the five causes and record the outcome.
The office projects show coordination RFIs clustered where ductwork crosses transfer beams, mostly raised early in steel erection and often followed by revised details. The school renovations show field condition RFIs tied to concealed structure. The firm adds a structural and mechanical overlay check before issuing construction documents, and starts proposing a broader existing conditions investigation in renovation fee proposals.
Why a tagged RFI log is a better record#
A tagged RFI log is a better record because it connects the question, the cause, the answer and the consequence. Untagged logs hold the same facts but force every reader to reconstruct the story from scratch.
That structure pays off internally, in training new project managers and in sharpening QA/QC checklists. It is also the kind of record AI developers look for when they study how technical work actually gets done. In the SourceX Enterprise Data Value Framework, linked decision records rate higher on human-generated signal, domain expertise and AI utility than isolated documents, while names and project identifiers add privacy burden that preparation has to remove.
How SourceX looks at RFI logs#
SourceX treats RFI logs as one record family in the Supply step of the SourceX five-step transaction, followed by Rights, Preparation, Approval and Delivery. RFIs often sit in projects hosted by an owner or contractor, so the rights review checks who controls each log before anything else happens.
Client, contractor and personal names come out during preparation, and the firm approves the final scope. Any package that moves forward is documented in a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Who should do the tagging?
Someone who can read drawings and responses with judgment, usually a senior project manager or the QA/QC lead, paired with a second reviewer for a cross-check. Avoid having the designer of record tag their own projects alone; a fresh reader is more likely to separate clarification from missing information consistently.
Can software tag RFIs automatically?
Text classification tools can suggest tags, and some vendors now offer RFI analysis. Suggestions still need review against your definitions, especially the line between clarification and missing information, which depends on reading the response and the referenced sheet. Tag a set manually first so you have something reliable to check any tool against.
How often should we repeat the exercise?
Repeat it once a process change has had time to show up on new projects, or at a natural checkpoint such as an annual QA/QC review. Use the same tag definitions each time so the comparison is fair, and add new projects to the sample rather than replacing the earlier ones.
Do RFI response times belong in the analysis?
Yes, as a separate measure. Response time shows how the firm handles RFIs; cause shows why they arose. Track the dates raised and answered alongside any delay the contractor reported, but keep speed metrics from crowding out the cause tags, which are what point to design process fixes.
Can we analyze RFIs that sit in a contractor's Procore project?
For internal quality review, firms generally work from their own copies of RFIs they answered. Using those records outside the firm, including in any data license, raises ownership and confidentiality questions that depend on the project contracts, so check the agreements before any outside use.
Sources
- Procore's Extracts documentation says most Procore items download as PDFs, while documents and photos keep their original file type. Output is saved in an 'Extracts' folder organized by project name, extract date and time, tool and item. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.