The Submittal Coordination Problem Is 95 Years Old

Ask any project team what makes submittals painful and you won't hear “the drawing is hard.” You'll hear that the right people are in different places, working at different speeds, and every hand-off is a chance to lose the thread.
That is not a new problem. In 1931, Engineering News-Record put its finger on exactly this — decades before fax, email, PDFs, or the cloud.
A 1931 complaint that sounds like this morning
In its February 19, 1931 issue, Engineering News-Record described the trouble with the “approval of the shop drawings made by these remote and widely scattered agencies.”
On a large job the drawings passed among fabricators, subcontractors, engineers, and the architect — each in a different office, each adding time. The bottleneck was not the work itself. It was the coordination: getting the right people, in the right order, to look at the right version and sign off.
Why scattered approval is the hard part
A submittal has one job: get the right item to the right reviewer, come back with a clear answer, with everyone looking at the same version. When the reviewers are spread out and working in sequence, three things go wrong.
It is slow — each hop waits on the one before it. It is fragile — the wrong revision keeps circulating. And it is opaque — nobody can see where a submittal is actually stuck. None of that is about drawing ability. It is about distance and hand-offs.
The paper-era workarounds
The fix in 1904 was procedural: send the shop drawings “to the architect, in duplicate,” stamp them, log them, mail them back. It worked, slowly. But every copy was another chance for versions to drift and for the paper trail to break — which is precisely how you end up, by 1931, complaining about approvals lost among “remote and widely scattered agencies.”

Email didn't fix it — it just moved faster
Fax, then email and PDF, made transmission instant. The copy that took days to mail now takes seconds to send. But the coordination problem stayed exactly where it was: still scattered, still sequential, still version chaos spread across inboxes and shared drives.
Faster transmission of a broken process is still a broken process. The 1931 bottleneck survived the arrival of the fastest communication tools in history because those tools sped up the sending — not the coordinating.
Fixing coordination, not just transmission
The 1931 complaint is finally addressable — but not by sending copies faster. It's addressable by removing the scatter: one shared place where the submittal lives, everyone on the same current version, review that happens in parallel instead of as a relay, and a live status so you can see exactly where each item is stuck and who owns the next move.
That is the difference Submittal.app is built on. Same review loop the industry has run since 1902 — minus the ninety-five-year-old coordination problem.
Sources
Frequently asked questions
What did the 1931 article actually say?
Engineering News-Record (February 19, 1931) referred to shop drawings whose approval was “made by these remote and widely scattered agencies” — a description of the delay that comes from routing approvals through dispersed parties.
Why is coordinating submittals still hard today?
Because reviewers are still dispersed and often review in sequence. The hard parts are version control, visibility into where an item is stuck, and enabling parallel review — not producing the drawing itself.
How does software actually change this?
By replacing scattered copies with one shared source of truth: a single current version, parallel review instead of a relay, and a live status for every item — so coordination stops being the bottleneck.
Take the scatter out of your submittals.
One shared place, one current version, parallel review, and a live status on every item — so coordination stops being the bottleneck.
Try Submittal.app free