Submittals & Shop Drawings

Six weeks before a hotel's grand opening, a general contractor's project engineer gets a call from the millwork fabricator: the custom lobby reception desk is finished and ready for delivery. There's just one problem. The shop drawings for that desk are still sitting in the architect's review queue, stamped, as of yesterday, "revise and resubmit," over a dimension that doesn't actually match the electrical rough-in behind it. The fabricator built the whole thing anyway, betting the drawings would get approved as submitted. They didn't, and now an expensive, custom piece of millwork needs to be reworked, or worse, rebuilt, on a schedule with no slack left in it. That fabricator built at risk, ordering and fabricating before the approval loop actually closed, and it's one of the single most expensive mistakes a subcontractor or supplier can make on a project. The submittal process exists precisely to prevent this: shop drawings, product data, and samples get reviewed and approved by the architect or engineer before anything gets ordered or built, confirming what's about to happen actually matches what was designed. Understanding that process well enough to actually manage it, not just recognize the paperwork, is what this lesson is really about.

It's easy for a newcomer to mix up an RFI and a submittal, since both move through similar-looking logs and both involve sending something to the design team and waiting on an answer. They're actually solving two different problems. An RFI gets filed when the drawings or specs themselves are unclear, missing, or contradictory, a genuine question that needs an answer before work can proceed correctly. A submittal isn't a question at all: it's a confirmation, sent after the design intent is already clear, showing exactly what a contractor intends to install and asking the design team to verify it actually matches. Put another way: an RFI exists because something in the documents doesn't make sense yet; a submittal exists because something does make sense, and now needs to be checked against reality before it gets built. Confusing the two in the field usually shows up as a subcontractor treating a genuinely ambiguous drawing as if it were already settled, or treating a routine product confirmation as if it needed a full design decision, both of which slow a project down for the wrong reason.

Once a submittal actually reaches the architect or engineer, it doesn't just come back approved or rejected. There's real range in between, and knowing the difference matters. "Approved" means proceed exactly as submitted. "Approved as noted" means proceed, but incorporate the specific corrections the reviewer marked, without needing to send it back through another full review cycle. "Revise and resubmit" means stop: the submittal doesn't accurately represent what should be built yet, and a corrected version has to come back through review before anything moves forward, exactly the stamp the lobby desk's shop drawings came back with. An outright rejection means the wrong product or approach entirely, back to the drawing board. Every one of these exchanges travels with a transmittal, a cover document recording exactly what was sent, to whom, and when, independent of the submittal itself. It sounds like paperwork for paperwork's sake until a schedule dispute breaks out over whether a submittal was actually received on time, at which point the transmittal, not the memory of whoever sent it, is what actually settles the question.

Not every submittal can wait its turn in the normal project schedule. A long-lead item, custom elevators, switchgear, specialty mechanical equipment, can take months to manufacture and deliver, sometimes far longer than it would take to design and build everything else around it. If the submittal and approval process for that one item doesn't happen early, well before the rest of the project would normally need it, that single piece of equipment can end up dictating the entire project's completion date, no matter how efficiently everything else gets built. Recognizing a long-lead item early, and pushing its submittal to the front of the review queue rather than letting it wait its natural turn, is one of the more consequential judgment calls a project team makes. Miss it, and a building can sit essentially finished for months, waiting on one piece of equipment that should have been ordered before the foundation was even poured.

Back to that lobby desk. What actually should have happened is straightforward in hindsight: hold fabrication until the submittal cycle genuinely closes, whether that's a clean approval, an "approved as noted" the fabricator can build from immediately, or a "revise and resubmit" that gets corrected and cleared before a single board gets cut. None of that requires special expertise, just the discipline to treat "still in review" as exactly what it says, not yet approved, rather than a formality to build around. Keeping all of it straight, which submittals are moving, which are overdue, which are long-lead items that need to jump the queue, is exactly what a submittal log exists to track, and it's a defining part of a Project Engineer's job on most projects. It's also exactly why the role is such a common entry point into project management: the person who actually understands the state of every submittal on a job usually understands the state of the whole project. If you remember one thing from this lesson, make it this: a submittal isn't paperwork standing between a contractor and the real work, it's part of the real work, the actual mechanism that keeps a hundred different decisions made months apart from quietly drifting out of sync with each other. Skip the loop to save a few days, and the fabricator with the lobby desk is proof of exactly how expensive that shortcut can get.