Zero NCRs Across 32 Structural Pours: How Aditya Nagtilak's RFI Process Prevented Every Non-Conformance on a 97,000 Sq Ft Mall

Concrete doesn't wait.

Once the pump truck backs up to a 97,000 square foot mall and starts pouring, you have a window measured in hours, not days. If there's a rebar spacing conflict nobody caught, or a footing dimension that doesn't match the structural drawings, you don't stop mid-pour to file paperwork. You pour around the problem. Then you demo it, rework it, and explain to the owner why the schedule just slipped two weeks and the budget just grew by five figures.

I supervised 32 structural concrete pours on a commercial mall project in Pune, India. Three to six trade crews on-site every day. 11,500 cubic yards of concrete. 1,300 tons of rebar. The kind of project where one missed conflict between the drawings and the field turns into a non-conformance report that follows the project — and the field engineer — for years.

Zero major NCRs. Not one across all 32 pours.

That wasn't luck, and it wasn't because the drawings were perfect. Drawings are never perfect. It was because every conflict got caught on paper before it ever reached the formwork — through an RFI process that ran ahead of the schedule instead of behind it.

This is what an RFI actually is, how the process works from field to closeout, and where most field engineers get it wrong.

Expert Insight by

Aditya Nagtilak

MS Construction Management, Arizona State University — Field Engineering & Project Controls

Construction ManagementLinkedIn

Aditya Nagtilak holds a Master's in Construction Management from Arizona State University (4.00 GPA) and a B.E. in Civil Engineering from Pune University. He brings 3+ years of field engineering experience across heavy civil highway and commercial construction: as an Assistant Project Engineer on a 4-mile PPP highway segment where he managed Primavera P6 scheduling, utility relocations, and QA/QC across 150+ density tests, and as a Field Engineer on a 97,000 sq ft commercial mall where he prevented every major NCR across 32 structural pours through disciplined RFI management, tracked 60 submittals, and modeled 9 change events with schedule impact analysis.

Verified Expert

The first RFI I ever submitted was wrong. Not the question — the question was valid. A footing detail on the structural drawings showed a dimension that conflicted with the architectural plan by about 15 centimeters. The problem was real. But my RFI had no drawing references, no proposed resolution, and no markup showing the conflict. Engineering sent it back and asked me to resubmit with actual information.

That response took three days to get back. Three days where the concrete crew was waiting. Three days I could have avoided by writing the RFI correctly the first time.

An RFI — Request for Information — is a formal document the contractor sends to the architect or engineer of record when the construction drawings or specifications contain a conflict, ambiguity, or missing detail that prevents the field from building correctly. It is the primary mechanism for resolving design questions during construction.

But calling it "a formal document" misses the point. An RFI is a field engineer's early warning system. Submit it early enough and you catch the problem before concrete is poured, steel is erected, or utilities are trenched in the wrong location. Submit it late, and you're writing an NCR instead.

On the Pavilion Mall project, I tracked over 20 RFIs across 14 months. Every one started the same way: I found something in the field, or during a plan review, that didn't match what the drawings said. The question was never "should I submit this?" The question was always "how fast can I get the answer back before we reach that work area?"

Most online explanations of the RFI process read like a flowchart: identify, write, submit, respond, close. Clean. Orderly. Nothing like what actually happens on a jobsite.

Here is what the process actually looks like when you're running it across 32 structural pours with three to six trade crews working simultaneously.

Step 1 — Spot the Conflict

RFIs start in one of three places: you catch a discrepancy during plan review before the work starts, you find a conflict during a field inspection, or a subcontractor flags something that doesn't match the drawings.

On the mall project, I caught most conflicts during daily pre-pour inspections — walking the formwork, checking rebar placement against the structural drawings, and verifying embed locations. The earlier you catch it, the cheaper the fix. A rebar conflict caught during formwork inspection costs nothing to fix. The same conflict caught after the pour costs tens of thousands in demolition and rework.

Step 2 — Write the RFI

A good RFI gets answered in days. A bad one gets bounced back and eats a week.

The proposed resolution is what separates experienced field engineers from new ones. Engineering doesn't want to solve your problem from scratch. They want to validate or correct your solution. Give them something concrete to react to, and the turnaround drops from two weeks to three days.

Step 3 — Route and Track

Every RFI goes through a chain: field engineer to project engineer, project engineer to architect or engineer of record, response back down the same chain. On most projects, this runs through Procore or Bluebeam, which timestamps every step.

The critical metric is aging. How many days has this RFI been open? On the mall project, I tracked aging on every open RFI weekly. Any RFI approaching the work area's scheduled pour date without a response got escalated immediately. "Waiting for engineering" is not a status — it's a countdown to a forced decision in the field.

Step 4 — Receive the Response and Implement

The engineer's response comes back as one of three dispositions: "proceed as shown" (the drawings are correct, you misread them), "revise as noted" (here's the corrected detail), or "submit a change order" (this is a scope change, not a clarification).

Each disposition requires a different action. "Proceed as shown" means the field team needs to be told the original drawings are correct. "Revise as noted" means the IFC drawings need to be updated and the field team needs the new information before they reach that work area. "Submit a change order" means the project engineer needs to model the cost and schedule impact.

Step 5 — Close Out and Update IFC Drawings

An RFI is not closed when the answer comes back. It is closed when the corrected information is reflected in the IFC drawings and the field team is building from the updated set. I've seen projects where RFIs were "answered" months ago, but the field crew was still working from the old drawings because nobody updated the IFC set.

On the mall project, every closed RFI triggered an IFC update and a brief at the next day's coordination meeting. No exceptions.

The Pavilion Mall was a 97,000 square foot commercial project in Pune. Structural concrete, retail buildout, MEP coordination, and a schedule that didn't have room for rework. I was the field engineer from the first footing pour to the last slab.

Thirty-two structural pours. Zero major non-conformance reports.

Here's the system that made that happen.

The Daily Pre-Pour Routine

Every morning before the crews started, I walked the active work zones with the IFC drawings in hand. Formwork alignment against structural plans. Rebar spacing and cover against the detail sheets. Embed plate locations against the MEP coordination drawings. Column reinforcement schedules against the structural bar bending schedules.

Anything that didn't match — even by a few centimeters — got flagged. If it was a clear field error (wrong rebar size installed), the crew fixed it on the spot. If it was a conflict between the drawings themselves, it became an RFI before lunch.

The key was timing. I submitted RFIs tied to the three-week look-ahead, not tied to the current day's work. When I was inspecting a pour zone, I was also reviewing the drawings for the next two pour zones. That way, engineering had one to two weeks to respond before the crew reached that area.

Coordinating RFIs with Submittals

The mall project generated 60 submittals and 20+ RFIs. These two document streams aren't independent — they feed each other. A submittal for a specific rebar supplier might reveal that the available bar lengths require additional splices the structural drawing didn't account for. That becomes an RFI.

I maintained a combined tracking log: submittal status, RFI status, and the pour schedule, all in one view. If a submittal was still pending approval and the pour date was three weeks away, that was a red flag — even if the RFI was closed. Both documents had to be resolved before any pour.

What "Zero NCRs" Actually Means

It doesn't mean nothing went wrong. Conflicts existed on almost every pour — dimension mismatches, missing details, coordination gaps between structural and MEP drawings. What it means is that every conflict was caught, documented, and resolved through the RFI process before concrete went in the forms. The problems were real. The NCRs were prevented because the problems were caught on paper, not in concrete.

Every new field engineer confuses these three documents at least once. They all flow through the design team. They all involve construction drawings. They all affect the schedule. But they solve completely different problems, and using the wrong one wastes everyone's time.

The simplest way to remember it: an RFI asks "what should we build here?" A submittal asks "is this material acceptable?" A change order says "the scope has changed, and so has the price."

On the mall project, roughly 30% of my RFIs eventually fed into change events. An RFI revealed a scope discrepancy — not just a clarification — and the response from engineering was "this is a change, not a clarification." That's when the RFI closes and the change order process begins.

I've seen these on both projects — the highway and the mall. Different scales, same patterns. Every one of these mistakes turns a solvable paper problem into an expensive field problem.

Mistake 1: Submitting Reactive Instead of Proactive

The crew is setting formwork. Someone notices the embed plate location doesn't match the MEP drawings. Now the RFI is urgent. Engineering is rushed. The response is late. The pour gets delayed or the crew makes a field decision without documentation.

Proactive means submitting the RFI two to three weeks before the work area is active. Reactive means submitting it the day the conflict shows up in the field. The difference is the engineering response time you've given yourself.

Mistake 2: Vague Descriptions That Bounce Back

"Drawing conflict on Level 2" is not an RFI. It's a conversation starter. Engineering sends it back and asks for specifics. You've lost three to five days.

A real RFI says: "Structural drawing S-204, Detail 3, shows column C-14 footing at 1.2m x 1.2m. Architectural drawing A-102 shows a wall directly above with a different column grid alignment. Proposed resolution: confirm footing size matches structural intent and verify column grid at C-14."

Mistake 3: Not Tracking Aging

On the mall project, I had 20+ RFIs open across 14 months. Some were answered in three days. Some took three weeks. The ones that sat open the longest were the ones closest to causing a problem, because the pour schedule kept moving even when the RFI didn't.

Every week, I reviewed open RFI aging against the three-week look-ahead. If an RFI was aging past 10 days and the related pour was within the look-ahead window, I escalated to the project engineer the same day.

Mistake 4: Ignoring the Change Order Signal

Not every RFI is a clarification. Some reveal actual scope gaps — work that wasn't in the contract drawings because the design team missed it. When engineering responds with "add this detail" or "revise per attached sketch," that's not a clarification. That's added scope.

On the mall project, 9 of my RFIs led to change events. I modeled each one in MS Project, updating logic ties and durations, and the cumulative impact was 14 days of schedule shift. If those had been treated as simple clarifications instead of change orders, the contractor would have absorbed both the cost and the time.

Mistake 5: Not Updating IFC Drawings After Closeout

This is the one that gets field engineers in trouble months later. The RFI is answered. The response says "revise per attached." But nobody updates the IFC set. Three months later, a different crew in a different zone is building from the old drawing, and the same conflict that was already resolved creates a new NCR.

On the mall project, every closed RFI with a "revise" disposition triggered an immediate IFC update. No exceptions.

Before the mall, I was an assistant project engineer on a 4-mile PPP highway segment — the Pune-Shirur Highway. Heavy civil. Earthwork, subgrade, utility relocations, asphalt paving. Four subcontractors and six crews daily.

The RFI process was the same. The stakes were different.

Highway: Utility Conflicts Can Shut Down a Work Front

On a highway project, the most dangerous RFI you can miss is a utility conflict. Power lines, water mains, fiber optic cables — they're all buried along the right-of-way, and the utility drawings from the municipality are rarely accurate. I managed utility relocations for power, water, and fiber across seven months. Zero utility strikes.

That record didn't come from luck. It came from sequencing: before any excavation in a new zone, I cross-referenced the utility drawings with the grading plan, flagged every potential conflict, and submitted RFIs to the utility agencies for verification. If the response wasn't back before the excavation was scheduled, the excavation didn't start. No exceptions.

On a highway, a utility strike doesn't just cost money. It shuts down the entire work front — sometimes for days while the utility company repairs the damage and the contractor documents the incident. One strike can cascade across the critical path for weeks.

Mall: Structural RFIs Happen on a Pour-by-Pour Basis

On commercial construction, the rhythm is different. Structural pours are the heartbeat of the schedule. Every pour has a hard sequence — excavation, forming, rebar placement, embed installation, pre-pour inspection, concrete placement, curing. An unresolved RFI at any point in that sequence can stop the pour or, worse, allow a defective pour to proceed.

The coordination complexity is also higher. On the highway, most RFIs were between the contractor and the design engineer. On the mall, every RFI potentially involved the structural engineer, the architect, the MEP coordinator, and the owner's representative. More stakeholders means longer response times, which means you need even more lead time on your RFI submissions.

Not every RFI stays an RFI. On the Pavilion Mall project, 9 out of 20+ RFIs triggered change events. The engineering response came back not as a clarification, but as added scope — new details, additional reinforcement, modified dimensions that weren't in the original contract documents.

That's the moment an RFI stops being a question and starts being money.

The field engineer's job at that point is documentation, not design. I modeled each change event in MS Project: updated the logic ties between affected activities, revised durations based on the added work, and recalculated the critical path. The cumulative impact across all 9 changes was 14 days of schedule shift.

The 14-day impact mattered for two reasons. First, it justified schedule relief — the contractor wasn't late, the scope had changed. Second, it created the documentation for cost recovery. Without the RFI trail showing when the question was asked, what engineering's response was, and how the scope changed, the contractor has no paper trail to support the change order.

This is where Primavera P6 and MS Project become essential. On the highway project, I maintained S-curves and variance logs in P6 weekly, flagging 10+ critical path impacts early. On the mall, I used MS Project to model change events with logic tie updates and constraint modifications. Both tools told the same story: here's what the original schedule showed, here's what changed, and here's the documented reason why.