Ask a superintendent what killed their schedule last quarter and half the time it wasn't the weather or a no-show crew. It was a submittal that sat on somebody's desk for three weeks, got kicked back "revise and resubmit," and blew the lead time on a piece of equipment nobody could install without. By the time the approved shop drawing came back, the crew that was supposed to hang that unit had rolled off to another job.
Submittals are unglamorous. They're also one of the few things on a project where a two-line email delay in April turns into a two-week schedule slip in September. Field management software doesn't make the review itself faster — a busy architect is a busy architect — but it removes the parts of the process that quietly leak days: the lost paperwork, the "I thought you had it," the submittal that was approved a month ago that your foreman is still building around the old version of. Here's how the good tools actually earn their keep, and where they don't.
Why submittals belong on the field team's radar, not just the PM's
In a lot of offices, submittals live entirely with the project engineer and the PM. The super finds out a submittal is a problem when the work is already staged and the material isn't there. That's backwards. The person who most needs submittal visibility is the one building the look-ahead, because a submittal is nothing more than a constraint on a future activity — and constraints are the whole reason we plan three to six weeks out instead of just working off the master schedule.
When you sit down to build a weekly work plan, every activity you commit to should clear the same gate: is it actually ready to go? Submittal status is one of the first things on that make-ready checklist, right next to material on site, area available, and manpower. If the shop drawing for the storefront isn't approved, you don't schedule the storefront install, no matter what the baseline says. Field management software that surfaces submittal status where you're doing your planning — instead of buried in a separate log you have to go dig for — is what makes that discipline possible instead of aspirational.
The workflow, and where it leaks time
A submittal has a predictable life: the sub prepares it, the GC reviews and forwards, the architect and their consultants review, it comes back approved or marked up, and if it's marked up the whole loop runs again. Sounds simple. In practice, the leaks are all in the handoffs.
- The GC's own review sits. A submittal handed to a project engineer who's slammed can burn a week before it ever reaches the architect. Software that timestamps every step and shows a submittal aging in your court is uncomfortable — which is exactly the point.
- Nobody knows whose desk it's on. Without a tracked chain, "where's the mechanical submittal?" turns into three phone calls. A status field that says "with structural engineer since the 14th" ends the guessing.
- The approval comes back and dies in an inbox. This one's the killer. The submittal gets approved, but the field never hears about it, so the work doesn't get scheduled and the material doesn't get released. Automatic notifications to the super and the responsible foreman close that gap.
Good software routes submittals through the required reviewers automatically, timestamps each transfer, and nags when something stalls past its ball-in-court duration. None of that speeds up the actual reviewing. What it does is make sure the days a submittal spends "in review" are the only days it loses — not another week of it sitting in a pile because a person forgot.
Tie the submittal log to the schedule, or the log is just a filing cabinet
A submittal register that lives on its own is a compliance document. It tells you what's approved. It does not tell you what's about to hurt you. The value shows up when submittal status is connected to the activities that depend on it.
Think about a single item — say, the elevator. There's a submittal, then a shop drawing, then a long fabrication lead time, then delivery, then a multi-week install, then inspection. That's a chain, and the first domino is the submittal. If review runs two weeks long instead of the one week you assumed, every downstream date moves two weeks with it. A look-ahead that treats submittals as real constraints will flag that chain before the install date is at risk. A look-ahead that ignores them shows you a green bar right up until the week the crew shows up to nothing.
This is the practical case for running your short-interval schedule in a tool like LookAheadWall rather than a static spreadsheet: when you build the trade-flow sequence for an area, the submittal status feeding those activities travels with the plan. You're looking at the constraint and the work in the same place, at the same time, instead of reconciling two documents in your head.
Build the lead time backward from install, not forward from approval
Here's a rule of thumb that saves more schedules than any piece of software: for any long-lead item, work the whole chain backward from the date you need it installed, and put the submittal deadline at the front.
Take switchgear with a 16-week fabrication lead. You need it energized before finishes start. Count back: install and terminate, delivery window, 16 weeks of fab, then the submittal and shop drawing review — and review is rarely under two to three weeks with a resubmittal cycle baked in. Add it up and the submittal has to be approved something like 20-plus weeks before you need power. That means it has to be in review even earlier. On a fast job, that submittal is due within the first month, long before anyone's thinking about switchgear.
The trap teams fall into is planning forward from approval — "once it's approved we'll order it" — which quietly assumes approval happens whenever. Plan backward, and the submittal gets a hard date driven by the install, and it lands on the look-ahead as a task with a deadline, not a hope. Software helps by tracking the full sequence from submittal to purchase order to delivery to installation, so you can see the day approval timing starts threatening the delivery, not the day it already blew it.
Resubmittals: plan for the second lap
Rookie schedules assume every submittal gets approved on the first pass. Anyone who's run a job knows better. "Approved as noted" and "revise and resubmit" are common, and each round trip can add a couple of weeks. Build your critical submittals with at least one resubmittal cycle of buffer, especially anything MEP or fabrication-heavy where coordination comments are basically guaranteed.
Where software helps on the second lap is routing and speed. Rejection comments get pushed straight back to the sub instead of relaying through three people, the resubmittal comes back into the same tracked chain, and the schedule impact of the extra loop is visible immediately rather than discovered later. What software can't do is make a sub who's slow to correct their drawings suddenly fast — so on the items that matter, you're still picking up the phone.
Shop drawings need coordination, not just a rubber stamp
Design approval and coordination are two different animals, and MEP is where they collide. A duct submittal can be perfectly approved on its own and still clash with the sprinkler main and the structural beam once you overlay everything above the ceiling. If you schedule overhead rough-in off individually approved shop drawings without a coordinated set, you're setting up a rip-out.
Treat coordinated shop drawings as their own constraint on overhead work. On a tight plenum, the sequence is: each trade submits, they run coordination together, conflicts get resolved on the composite, then — and only then — does overhead rough-in get scheduled area by area. Your look-ahead should reflect the actual coordination status of the area you're about to open up, not the count of individually approved submittals. This is exactly the kind of gotcha that a location-based weekly plan catches: you're planning by area, so the question "is the coordination done for this zone?" is right in front of you.
Get the approved documents into the field's hands
An approved submittal that only exists in an office file server isn't doing your crew any good. The classic failure: a shop drawing gets revised and re-approved, but the foreman is still building off the printout tacked to the gang box from six weeks ago. Now you've got installed work that doesn't match the current approved version, and that's a rework conversation nobody enjoys.
Mobile access to current approved documents is one of the quieter wins here. When the approved submittal and the latest revision are on the phone in the foreman's pocket, "are we building to the right version?" stops being a question. Make document-current verification a make-ready item before a crew opens up an area — same checklist as material and access. It takes thirty seconds and it prevents the ugliest kind of rework, the kind you built exactly to spec, just the wrong spec.
Watch the numbers, and manage the reviewer's plate
Once you're tracking submittals in a system, you get history — and the history is worth reading. Average review time by reviewer tells you which consultant to build extra buffer around. Rejection and resubmittal rates by trade tell you which subs need their submittals pushed early and watched closely. After a few projects, that data makes your look-aheads more honest, because you're planning off what review actually takes on your jobs, not the optimistic number in the contract.
One last field-level point that's easy to miss: the design team has finite bandwidth. Dump forty submittals on an architect in the same week and the whole queue slows down, including the ones on your critical path. Part of managing submittals well is metering the flow — sequencing them so the schedule-critical items hit the reviewer's desk when there's room to actually look at them, and not letting a pile of low-priority finish submittals bury the one piece of equipment that gates your whole electrical rough-in. That's a coordination judgment call, and no software makes it for you. But a system that shows you the whole queue and what's aging in it is what lets you make the call on purpose instead of by accident.
The bottom line
Field management software doesn't approve your submittals and it doesn't shorten a real review. What it does is take submittals out of the shoebox and put them where they belong — as tracked, dated constraints hanging off the activities in your look-ahead. Do that, plan the lead times backward from install, buffer the ones that'll bounce, keep coordination separate from approval, and get current documents into the field, and submittals stop being the quiet thing that ambushes your schedule in the back half of the job. They become just another constraint you clear before the crew shows up — which is exactly what short-interval planning is for.