Submittals and RFIs, explained: the two logs that keep a job from stalling

A construction project rarely stalls on the work itself. The crew is ready, the material's on the way — and then it waits, because a shop drawing is sitting unreviewed on someone's desk, or a question about a conflicting detail went out three weeks ago and nobody answered it. Jobs stall on paper. Submittals and RFIs are that paper, and the difference between a project that flows and one that lurches is almost always how well those two logs are kept.

This is a plain-English look at what submittals and RFIs actually are, how they differ, why "ball-in-court" is the single most useful thing to track about either one, and how a clean, dated log quietly protects both your schedule and — if it ever comes to it — your delay claim.

What a submittal is

A submittal is the contractor's proof, before fabricating or installing something, that what they intend to provide matches what the contract documents require. It's the checkpoint between "the drawings say a pump" and "here is the exact pump we're going to install — approve it." Submittals come in a few flavors:

• Shop drawings — detailed fabrication or installation drawings, made by the contractor or a sub, showing exactly how a component will be built (structural steel, ductwork, casework).
• Product data — manufacturer cut sheets proving a specified product meets the spec.
• Samples — physical examples of finishes, colors, materials for approval.
• Other — mix designs, certifications, warranties, O&M data, and the like.

Each submittal goes out against a spec section, gets reviewed by the architect or engineer, and comes back with a review action — approved, approved as noted, revise and resubmit, or rejected. Until it comes back approved, the smart contractor doesn't order or build the thing. That's the whole point of the process: catch the mismatch on paper, where fixing it costs an email, instead of in the field, where it costs a tear-out.

What an RFI is — and how it's different

An RFI (Request for Information) is a formal question. When the documents are unclear, contradict each other, or collide with a field condition, the contractor writes it up and asks the design team for a written answer. Where a submittal says "here's what I plan to provide — confirm it's right," an RFI says "I can't proceed until you tell me which is right."

The distinction matters because RFIs carry two consequences a submittal usually doesn't: an RFI can have a cost impact and a schedule impact. A question that stops work, or whose answer changes the scope, is the seed of a potential change order and a potential delay. That's why a good RFI log flags cost and schedule impact on every entry — those flags are your early warning that a simple question is about to become a claim.

Ball-in-court: the number that actually moves the job

You can track a dozen fields on a submittal or an RFI, but if you track only one, track ball-in-court — whose desk the item is sitting on right now. Every open submittal and every open RFI is, at any moment, waiting on exactly one party: the contractor (to submit or revise), the architect or engineer (to review or answer), or the owner (to decide). Ball-in-court answers the only question a project manager really has at the weekly meeting: who do I need to push, and on what?

Summed across the whole log, ball-in-court becomes a management tool. "Eleven items open, seven in the architect's court" is a specific, defensible thing to raise in the meeting — far more useful than a vague "we're waiting on some stuff." It turns chasing paperwork from nagging into accountability, because the count is right there and it's not personal, it's just the log.

Why aging and dates protect you

The other half of a good log is time. Two views turn a static list into an early-warning system:

• Overdue flags. Every submittal has a date it's required back by (driven by the fabrication and delivery lead time), and every RFI has a needed-by date. An item past that date should light up on its own, before it becomes the reason the crew is standing around.
• Aging buckets. Grouping open items by how long they've been out — say 0–7, 8–14, 15–30, and 30+ days — surfaces the ones drifting toward trouble while there's still time to escalate. The 30+ column is where schedules quietly die.

And then there's the reason every dated entry earns its keep even when the job goes fine: the record. If a project ends up in a delay dispute, the submittal and RFI logs are among the first documents anyone asks for. A log that shows an RFI sat unanswered for 40 days, with the dates to prove it, is the difference between "we think the design team held us up" and a documented, time-stamped fact. You keep the log to run the job — but the log you kept to run the job is also the log that defends it.

Keeping it without a full-time PM

You don't need enterprise project-management software to run submittals and RFIs well — a small GC or sub can do it from one spreadsheet with a few disciplines:

• Number everything, log it the day it moves. Every submittal and RFI gets a number and a row the moment it's created. An item that only lives in an email thread is an item you'll forget until it's late.
• Always record the date and the ball-in-court. Those two fields do most of the work. Date out, date back, and whose court it's in right now.
• Review the open items every week. Sort by aging, look at the overdue and the 30+ bucket, and take the ball-in-court summary to the meeting. Five minutes that saves a stalled week.
• Flag cost and schedule impact on RFIs immediately. The moment a question looks like it changes scope or time, mark it — that's the flag that keeps a claim from ambushing you at closeout.

Submittals prove the right thing gets built; RFIs get the answers that let the work proceed. Both are just questions waiting on answers — and the job moves at the speed you keep those questions from getting lost. Keep the two logs clean, watch the ball-in-court and the aging, and the paperwork stops being what stalls the project and starts being what keeps it honest.

This is general information about construction project documentation, not legal, contract, or design advice. Submittal and RFI procedures, review times, and notice requirements are set by your project's specifications and contract — follow those, verify against your own documents, and consult a qualified professional for your project's specific requirements.