Architectural Rfi Decision Tracking Checklist for Small Architecture Firms And Design-Project Administrators

A checklist for architectural RFI decision tracking should prevent missing decisions, not merely prove that somebody clicked boxes. The checklist below is designed for small architecture firms and design-project administrators and centers on one result: every RFI response identifies the authoritative decision, impact, and required document updates before operational closure.

Before the work starts

• Confirm Project and RFI number
• Confirm Question and location
• Confirm Referenced drawing or specification
• Confirm Originator and responsible party

Also name the owner and the expected completion condition. If either is unknown, the work is not ready to enter the active queue.

While the work is moving

• Update Register the question and governing references
• Update Assign the decision owner and needed-by date
• Update Develop and approve the response
• Update Assess cost, schedule, and document impact
• Update Distribute the decision and verify follow-through

Every update should change a decision. Notes such as “followed up” are weak unless they also include the channel, result, next date, and owner.

Before marking it complete

• Verify Needed-by date
• Verify Approved response and attachments
• Verify Cost, schedule, and scope impact
• Verify Distribution and document-update evidence

Confirm that the actual outcome—not just an activity—has been recorded. If the process ended early, use a closed reason rather than deleting the record.

Copy-and-paste weekly review

• [ ] Review records where an rfi approaches its needed-by date without a decision

• [ ] Review records where the response changes cost, schedule, scope, or controlled documents

• [ ] Review records where field conditions or a revision supersede the published response

• [ ] Check for closing when a response is posted but drawings still conflict

• [ ] Check for answering a different question than the cited condition

• [ ] Check for letting an informal field direction bypass the register

• [ ] Check for overwriting a response without marking the superseded version

Make the checklist measurable

Choose one metric before the next cycle. Good options for this workflow are Response cycle time, Past-needed-by backlog, Follow-through completion. A checklist that never changes a metric or prevents a known failure mode is probably administrative overhead.

Assign ownership and escalation

Put one role—not a group—next to every item that can remain open. Define a backup owner and an escalation time for work that affects a customer, client, participant, or delivery promise. During review, separate not started, waiting on someone, and failed validation; those states need different actions. If a checklist item repeatedly waits on the same dependency, redesign the intake or handoff instead of adding more reminder boxes.

Next step

Explore the RFI Decision Register workflow concept and record whether this is painful enough to justify a focused tool.

For the adjacent workflow, see Consultant Deliverable Board.