Hey {{first_name | default: "there"}},
Most PMs treat RFIs as questions. Submit, wait for the answer, close it out, move on.
That's not wrong. It's just half the job.
THE LESSON
Every RFI you submit is also a timestamp. Date issued, who it went to, how long it sat, what the answer changed. That's the contemporaneous record of every design gap the owner's team created on your project.
The PM who logs the date, the response time, the schedule impact, and the CO cross-reference on every RFI has a delay claim built by the time the project is over. They didn't build it on purpose. They built it by keeping a real log.
The PM who logs "submitted / answered" has a list of questions and nothing else.
I had a project where the A/E was running 18-21 days on RFI responses against a 7-day contract requirement. We were logging them, but only the basics — number, date, subject, status. No response time calculation. No schedule impact flag. No connection to which activity was waiting. Eight months in, I knew the RFI backlog had contributed to our schedule slippage. I couldn't prove it. The claim didn't go anywhere.
Here's the thinking shift: every time you log an RFI, ask two additional questions. Does this RFI affect any scheduled activity, and if so, which one? And what's the contractual response deadline? Those two answers turn a tracking log into a delay claim foundation.
Once you have a log that's been capturing that data consistently, AI becomes genuinely useful. Export the log, give it to Claude, and ask it to identify the RFIs with the highest schedule impact based on response times and affected activities. Ask it to calculate the total delay attributable to RFI response overruns. What takes a PM a day to analyze manually takes a few minutes with a clean data set. The key word is clean — the analysis is only as good as what you logged in real time.
THE TOOL
The RFI Log tab in the PM Edge Project Tracker has days-open as a live formula — updates automatically whether the RFI is open or closed. There's a schedule impact flag column and a CO cross-reference column on every row. When you close an RFI, days-to-respond calculates automatically.
At the end of the project — or in the middle of a dispute — you filter to every RFI with a schedule impact flag and a response time over 14 days. That's your delay claim foundation, built in real time by the act of keeping the log correctly.
If you don't have the tracker: PM Edge Project Tracker — $49 →
Already have the Toolkit? Bundle both for $69 →
INDUSTRY PULSE
On my radar:
• RFI volumes are rising on design-bid-build projects — Average RFI counts on mid-size commercial projects are up 22% in 2025-2026, driven by compressed design schedules and late-stage value engineering. More RFIs means more response delay exposure. Log them like the claims documentation they are.
• A/E response time disputes are increasingly litigated — Courts are giving more weight to contractually-specified RFI turnaround requirements. If your contract has a 7-day or 14-day response requirement and you documented every overrun, that's quantifiable owner-caused delay. If you didn't document it, it's a story.
• Design-assist contracts shift the RFI dynamic — On design-assist and design-build projects, RFI response obligations may fall on the contractor's design team. Know which direction the obligation runs on your contract before you assume the A/E clock applies.
Forward this to a PM who's ever known a delay was real but couldn't prove it.
— Jesse
The PM Edge | pmedge.io