RFIs and Submittals Don't Belong in Your Inbox: A Project Controls Argument Worth Having

Every project manager has done this. You're on a call with the GC, they ask about an RFI status, and you put them on hold while you dig through your inbox. You search the job number, then the engineer's name, then "submittal," then "re: re: re: re:", and somewhere in there is the answer. Three minutes of searching for a single data point that should have been visible in thirty seconds.

That's not a workflow problem. That's a structural problem. And it's worth arguing about.

Why Email Is the Wrong Home for RFIs and Submittals

Email is built for conversations. It is not built for status tracking. The moment an RFI gets sent by email, it stops being a project record and starts being a personal message in someone's inbox. From that point on:

• Only one person can see it without being forwarded a copy.
• Nobody outside that thread knows it's outstanding.
• "Ball in court" is whatever you can remember from the last reply.
• The open list of questions and approvals doesn't exist as a list, it exists as a search.

For a ten question project this is annoying. For a mixed service and project shop running several active jobs at once, HVAC mechanical work at a Mississauga industrial site, electrical for a Scarborough retrofit, a facilities contract downtown, it compounds fast. An unanswered question about drawings can stop a crew. An approval waiting on a material submittal can push a rough in inspection by a week. The delay doesn't show up in the schedule until it's already too late to absorb it.

The question project managers argue about is this: is email actually that bad, or are we just not disciplined enough about how we use it?

It's a fair argument. Here's the case for both sides.

The Case for Email (and Why It Keeps Winning)

Email wins because it's already there. Every engineer, architect, general contractor, and authority having jurisdiction already has it. Sending an RFI by email is frictionless. Getting a response back into a project management system is not, it requires someone to copy and paste, update a field, and remember to close the loop. When the project team is spread across a job site, a supplier warehouse, and an office in Etobicoke, the lowest friction tool wins by default.

The discipline argument has some merit too. A shared inbox with a clear tagging system, a dedicated project folder structure, and a weekly review can work, for a while, on a smaller project, with a single dedicated PM.

But it fails at exactly the moment you need it most: when the project is moving fast, the PM is on site, a crew is waiting on an answer, and nobody has time to maintain the system they were supposed to be maintaining.

The Case for a Log

A proper RFI and submittal log does one thing email cannot: it makes the outstanding list a list.

That sounds obvious. It isn't. The list only works if:

1. Every RFI and submittal is entered when it's created, not after it's resolved.
2. Each entry carries its own status (open, pending, approved, rejected, resubmit).
3. Each entry shows who holds the ball, the GC, the engineer, the owner, your team.
4. The log is attached to the project, not to a person's inbox.

When those four conditions are met, a five second glance at the log tells you everything a three minute email search used to tell you. More importantly, it tells the same thing to everyone on the project team at the same time: the PM, the site super, the ops lead back at the office, and the owner asking questions on a Friday afternoon.

The concrete version of this: picture the monitor in a site trailer showing the open RFI log for an active job. Each row is a question or a material approval. Status columns are colour coded. Ball in court is a name, not a memory. The drawings are linked beside it. That's not a sophisticated setup, it's a list with four fields. The sophistication is that the list exists at all.

A Simple Framework: What Your RFI and Submittal Log Needs

If you're building or fixing a log right now, here's what each entry needs to be useful:

• Item number and type (RFI 001, Submittal 004, etc.)
• Description, one line: what question was asked or what material is pending approval
• Date submitted
• Required response date (not the same as the contract deadline, the date YOU need the answer to keep your schedule)
• Current status (open, pending review, approved, rejected, revise and resubmit)
• Ball in court, the person or company who needs to act next
• Date closed

That's eight fields. You can run this in a spreadsheet if you have the discipline to update it. The problem is that discipline, again, a spreadsheet is not attached to anything. When a question gets answered, someone has to go update it. When a new RFI comes in, someone has to remember to add it. The log and the project live separately, and keeping them in sync is a task that gets dropped when the project gets busy.

Where PolarPath Fits

PolarPath's project controls module logs each RFI and submittal directly against the project. When a question gets raised or a material goes out for approval, it lives on the project record, not in someone's email, not in a separate spreadsheet. Status and ball in court are fields on the item. The open list is just the filtered view of items that aren't closed yet.

Your project manager sees each question and material approval on the project, with its status and the person who needs to answer. No inbox search. No "I think we're still waiting on that" conversation. The list is the list.

This matters more for shops running both service calls and project work, where the same ops lead who dispatched a crew to a Brampton service ticket this morning is also tracking submittals on a multi month mechanical project. The two workflows are different in pace and complexity, but the log problem is the same.

PolarPath sits on the operational execution layer and keeps working alongside QuickBooks for the financials, so the project controls your PM needs and the accounting your controller needs stay in their respective homes without forcing a fight between systems.

The Practical Takeaway

Start the log before you send the first RFI, not after the first one gets lost. An RFI log that gets built retroactively is archaeology, not project control. Set up the four required fields (status, ball in court, required response date, description), attach it to the project, and review it at every site meeting. If you're doing it in a spreadsheet today, that's fine, just make sure someone owns updating it in real time, not weekly.

And the question worth arguing about in your shop: who is responsible for maintaining the RFI log, the PM who sends the questions, or a dedicated coordinator who tracks all correspondence? How does your team handle it right now?

PolarPath is built in the Greater Toronto Area for field service and project contractors who run both. Learn more at polarpath.ca.

Les DDI et les soumissions n'ont pas leur place dans votre boîte de réception : un débat qui mérite d'être eu en gestion de projet

Tout gestionnaire de projet l'a déjà vécu. Vous êtes en appel avec l'entrepreneur général, il vous demande où en est une DDI, et vous le mettez en attente pendant que vous fouilllez dans votre boîte de réception. Vous cherchez le numéro de chantier, puis le nom de l'ingénieur, puis « soumission », puis « rép. : rép. : rép. : rép. : », et la réponse se trouve quelque part là dedans. Trois minutes de recherche pour un seul point d'information qui aurait dû être visible en trente secondes.

Ce n'est pas un problème de flux de travail. C'est un problème de structure. Et ça mérite qu'on en débatte.

Pourquoi le courriel n'est pas le bon endroit pour les DDI et les soumissions

Le courriel est conçu pour les échanges. Il n'est pas conçu pour le suivi des statuts. Dès qu'une DDI est envoyée par courriel, elle cesse d'être un document de projet pour devenir un message personnel dans la boîte de réception de quelqu'un. À partir de là :

• Une seule personne peut la consulter sans qu'on lui en transfère une copie.
• Personne en dehors du fil de discussion ne sait qu'elle est en attente.
• La balle est dans le camp de celui dont vous vous souvenez de la dernière réponse.
• La liste des questions et des approbations ouvertes n'existe pas en tant que liste, elle existe en tant que recherche.

Pour un projet de dix questions, c'est agaçant. Pour un atelier mixte service projet qui gère plusieurs chantiers actifs à la fois, travaux mécaniques de CVC sur un site industriel à Mississauga, électricité pour une rénovation à Scarborough, un contrat de maintenance au centre ville, ça s'accumule rapidement. Une question sans réponse sur des plans peut arrêter une équipe. Une approbation en attente sur une soumission de matériaux peut repousser une inspection de décloisonnement d'une semaine. Le retard n'apparaît pas dans le calendrier avant qu'il soit déjà trop tard pour le rattraper.

La question que les gestionnaires de projet se posent est la suivante : le courriel est il vraiment si mauvais, ou manque t on simplement de rigueur dans la façon dont on l'utilise ?

C'est une question légitime. Voici les arguments des deux côtés.

L'argument en faveur du courriel (et pourquoi il continue de l'emporter)

Le courriel l'emporte parce qu'il est déjà là. Chaque ingénieur, architecte, entrepreneur général et autorité compétente l'utilise déjà. Envoyer une DDI par courriel est sans friction. Faire revenir une réponse dans un système de gestion de projet ne l'est pas, cela exige que quelqu'un copie colle, mette à jour un champ et se souvienne de fermer la boucle. Lorsque l'équipe de projet est répartie entre un chantier, un entrepôt de fournisseur et un bureau à Etobicoke, l'outil le moins contraignant s'impose par défaut.

L'argument de la rigueur a aussi du mérite. Une boîte de réception partagée avec un système d'étiquetage clair, une structure de dossiers dédiée par projet et une révision hebdomadaire peuvent fonctionner, pendant un certain temps, sur un projet plus petit, avec un seul gestionnaire de projet dédié.

Mais ce système tombe en panne exactement au moment où vous en avez le plus besoin : quand le projet avance vite, que le gestionnaire est sur le chantier, qu'une équipe attend une réponse, et que personne n'a le temps de maintenir le système qu'on était censé maintenir.

L'argument en faveur d'un registre

Un registre de DDI et de soumissions digne de ce nom fait une chose que le courriel ne peut pas faire : il transforme la liste des éléments en attente en une vraie liste.

Cela semble évident. Ça ne l'est pas. La liste ne fonctionne que si :

1. Chaque DDI et chaque soumission est saisie au moment de sa création, pas après sa résolution.
2. Chaque entrée porte son propre statut (ouverte, en attente, approuvée, rejetée, à resoumettre).
3. Chaque entrée indique qui a la balle, l'EG, l'ingénieur, le propriétaire, votre équipe.
4. Le registre est associé au projet, pas à la boîte de réception d'une personne.

Lorsque ces quatre conditions sont remplies, un coup d'œil de cinq secondes sur le registre vous donne tout ce qu'une recherche de trois minutes dans les courriels vous donnait autrefois. Plus important encore, il donne la même information à tous les membres de l'équipe de projet en même temps : le gestionnaire, le contremaître sur le chantier, le responsable des opérations au bureau et le propriétaire qui pose des questions un vendredi après midi.

Voici une image concrète : imaginez l'écran dans une roulotte de chantier qui affiche le registre des DDI ouvertes pour un projet actif. Chaque ligne est une question ou une approbation de matériau. Les colonnes de statut sont codées par couleur. La balle dans le camp est un nom, pas un souvenir. Les plans sont liés à côté. Ce n'est pas une configuration sophistiquée, c'est une liste avec quatre champs. La sophistication, c'est que la liste existe.

Un cadre simple : ce que votre registre de DDI et de soumissions doit contenir

Si vous créez ou corrigez un registre en ce moment, voici ce que chaque entrée doit contenir pour être utile :

• Numéro d'élément et type (DDI 001, Soumission 004, etc.)
• Description, une ligne : quelle question a été posée ou quel matériau est en attente d'approbation
• Date de soumission
• Date de réponse requise (pas la même chose que l'échéance contractuelle, la date à laquelle VOUS avez besoin de la réponse pour respecter votre calendrier)
• Statut actuel (ouverte, en cours d'examen, approuvée, rejetée, à réviser et resoumettre)
• Balle dans le camp, la personne ou l'entreprise qui doit agir ensuite
• Date de clôture

Cela fait huit champs. Vous pouvez gérer ça dans un tableur si vous avez la rigueur de le mettre à jour. Le problème, encore une fois, c'est cette rigueur, un tableur n'est associé à rien. Quand une question reçoit une réponse, quelqu'un doit aller le mettre à jour. Quand une nouvelle DDI arrive, quelqu'un doit penser à l'ajouter. Le registre et le projet vivent séparément, et les maintenir synchronisés est une tâche qu'on laisse tomber quand le projet devient chargé.

La place de PolarPath

Le module de contrôle de projet de PolarPath enregistre chaque DDI et chaque soumission directement dans le projet. Quand une question est soulevée ou qu'un matériau part en approbation, l'information est consignée dans la fiche du projet, pas dans le courriel de quelqu'un, pas dans un tableur distinct. Le statut et la balle dans le camp sont des champs associés à l'élément. La liste ouverte n'est que la vue filtrée des éléments qui ne sont pas encore clôturés.

Votre gestionnaire de projet voit chaque question et chaque approbation de matériau dans le projet, avec son statut et la personne qui doit répondre. Pas de recherche dans la boîte de réception. Pas de conversation « Je crois qu'on attend encore ça ». La liste, c'est la liste.

Cela compte davantage pour les ateliers qui gèrent à la fois des appels de service et des projets, où le même responsable des opérations qui a envoyé une équipe sur un appel de service à Brampton ce matin assure aussi le suivi des soumissions sur un projet mécanique de plusieurs mois. Les deux flux de travail diffèrent par leur rythme et leur complexité, mais le problème de registre est le même.

PolarPath se situe sur la couche d'exécution opérationnelle et fonctionne en parallèle avec QuickBooks pour les finances, ainsi, les contrôles de projet dont votre gestionnaire a besoin et la comptabilité dont votre contrôleur a besoin restent chacun dans leur environnement respectif, sans forcer un conflit entre les systèmes.

Ce qu'il faut retenir

Commencez le registre avant d'envoyer la première DDI, pas après que la première ait été perdue. Un registre de DDI construit après coup, c'est de l'archéologie, pas du contrôle de projet. Configurez les quatre champs requis (statut, balle dans le camp, date de réponse requise, description), associez le au projet et passez le en revue à chaque réunion de chantier. Si vous le faites dans un tableur aujourd'hui, c'est acceptable, assurez vous simplement que quelqu'un est responsable de le mettre à jour en temps réel, et non de façon hebdomadaire.

Et la question qui mérite d'être débattue dans votre atelier : qui est responsable de la tenue du registre de DDI, le gestionnaire qui envoie les questions, ou un coordonnateur dédié qui suit toute la correspondance ? Comment votre équipe gère t elle ça en ce moment ?

PolarPath est conçu dans la région du grand Toronto pour les entrepreneurs en services sur le terrain et en gestion de projet qui font les deux. Pour en savoir plus, visitez polarpath.ca.