RFIs, submittals, and change orders are three different construction documents used to clarify information, verify proposed materials or methods, and formally change contract scope, time, or cost. Confusing them slows decisions and can create disputes.
Key takeaways for quick planning
- An RFI asks for clarification when drawings, specifications, or field conditions are unclear.
- A submittal shows how the contractor intends to satisfy a requirement.
- A change order changes the agreement and should not be treated like a casual field note.
Why these documents get mixed up
Construction projects produce questions because drawings and specifications cannot describe every field condition. The issue is not that questions occur. The issue is whether the team uses the right document for the right decision. The AIA Contract Documents library is widely recognized in the industry, and its forms show why formal documentation matters when scope, cost, and schedule are involved.
Beginners often treat RFIs, submittals, and change orders as paperwork with different names. In practice, they answer different business questions. What is unclear? What product or method will be used? What contract term is changing?
RFI: clarification without automatic change
A request for information should identify the specific drawing, specification, conflict, missing dimension, or field condition causing uncertainty. A good RFI includes a proposed interpretation when appropriate, but it should not be used to redesign the project by habit.
An RFI response may lead to no change, a minor clarification, a proposed change, or a formal change order. That sequence matters. Jumping straight from confusion to extra work without written direction is one way change disputes begin.
Submittal: proof of intended compliance
A submittal is usually a product data sheet, shop drawing, sample, mix design, equipment selection, or installation detail submitted for review against the contract documents. It does not usually rewrite the design intent. Instead, it helps the design team and owner confirm that the contractor is proposing something consistent with the project requirements.
For example, on a slab project, submittals may include concrete mix information. A beginner-friendly explanation of mix decisions appears in concrete mix basics, while the submittal itself should still follow the project specifications.
Change order: the contract adjustment
A change order is the formal path for agreed changes in scope, price, or time. The official AIA G701 Change Order form is one example of how the industry structures those changes. Teams should avoid using email approvals, meeting comments, or field assumptions as substitutes for the process required by their contract.
Quick comparison
| Document | Main purpose | Poor use |
|---|---|---|
| RFI | Clarify unclear or conflicting information | Creating a record for avoidable questions |
| Submittal | Show proposed products, shop drawings, samples, or methods | Pushing unapproved substitutions quietly |
| Change order | Modify contract scope, cost, or time | Treating informal comments as authorization |
Common document mistakes
- Using an RFI to request a product substitution without following substitution rules.
- Sending submittals that ignore specification sections or required test data.
- Performing extra work before written direction is clear.
- Writing vague change descriptions that do not separate labor, material, equipment, schedule, and exclusions.
- Failing to log response dates, reviewer comments, and revised submissions.
How the documents connect during a real issue
Imagine a wall detail conflicts with a mechanical route. The contractor submits an RFI asking which condition controls. The design team answers with clarification. If the answer requires a different product, the contractor may submit revised product data or shop drawings. If the answer changes cost or time, the contract may require a proposal and change order.
This sequence keeps the project record clean. It separates technical clarification from product review and formal contract adjustment. When those steps collapse into one vague email thread, teams may disagree later about who approved what and whether money or time was included.
Log discipline for small teams
Even small projects need logs. A basic spreadsheet or project management system should track document number, subject, responsible reviewer, date sent, date due, answer status, cost impact, schedule impact, and linked drawings. The log is not bureaucracy for its own sake; it is the memory of the project.
The best logs are reviewed in meetings before they become stale. Old RFIs, late submittals, and unresolved pricing questions should not hide until pay applications or closeout. A short weekly review can prevent paperwork from becoming a field delay.
How to write clearer RFIs
A strong RFI is specific. It should name the drawing or specification section, describe the conflict or missing information, explain field impact, and ask a direct question. Attach sketches or photos only when they clarify the question. Long background narratives without a clear ask slow the reviewer and often produce incomplete answers.
Avoid using RFIs to shift basic coordination responsibility. If the contract documents already answer the question, the RFI log becomes cluttered and real problems get less attention. Good teams protect the process by asking necessary questions well.
Submittal review is not design outsourcing
Submittals should demonstrate compliance with the design intent. They are not a shortcut for the contractor to redesign systems unless the contract allows delegated design or substitutions. Review stamps and comments should be read carefully because they may approve only general conformance, not every dimension, quantity, or installation detail.
When a submittal conflicts with the contract documents, the conflict should be resolved before procurement or installation. Buying materials before review can create schedule pressure that makes good decisions harder.
Closeout depends on clean records
The value of these documents continues after construction. RFIs may explain why a detail differs from the original drawing. Submittals may identify installed products, colors, equipment, or maintenance requirements. Change orders may explain why the budget or completion date changed.
When records are incomplete, facility teams inherit confusion. They may not know which product was installed, why a wall was rerouted, or which warranty applies. Good documentation is a gift to the people who operate the building later.
Decision speed without careless approval
Fast answers are helpful only when they are complete. A rushed RFI answer that ignores cost, schedule, or code implications can create more confusion than a slow one. The reviewer should answer the question asked, identify limitations, and flag when a separate change process is required.
The same principle applies to submittals. A quick approval that misses a specification conflict may push the problem into procurement or installation. Speed should come from good routing and clear responsibility, not from skipping review.
A cleaner paperwork path
A strong project team keeps the language simple: ask, verify, then change only when the contract process says to change. A clear scope of work can reduce many downstream document conflicts because responsibilities and exclusions are easier to see before construction starts. This article is educational only and is not legal, contract, or project management advice.
