Submittal Management in Construction: How GCC Contractors Stop Building Before Approval

The Cost of Building Before Approval

A MEP subcontractor on a SAR 95M commercial tower in Riyadh selected a chiller brand based on what the project engineer approved verbally on a site visit. Nine weeks later, the formal submittal came back rejected — the specified manufacturer had not been consulted, and the equipment failed to meet district cooling interface requirements. Replacement procurement added 11 weeks to the MEP programme and SAR 780K in unrecovered costs.

That scenario is not exceptional. It happens on GCC construction sites regularly, and the cause is almost always the same: no structured submittal management process, so procurement and installation races ahead of formal approval.

What Submittals Are — and What They Are Not

Submittals get confused with two other document types constantly:

Transmittals are the delivery mechanism — a structured dispatch record proving documents were sent to the right party.
RFIs are questions — the contractor asking the engineer to clarify design intent.
Submittals are approval requests — the contractor asking the engineer or client to confirm that a proposed material, product, or method meets the specification.

The three are related but not the same. A submittal gets transmitted to the consultant. If the consultant needs clarification before approving, they may raise an RFI in response. But collapsing all three into one unstructured email trail means none of them works properly.

Typical submittal types on a GCC construction project include product data (manufacturer data sheets for structural steel, rebar grades, concrete mix designs, MEP equipment), shop drawings (contractor detailed fabrication drawings for engineer review), material samples (physical finishes for colour or texture approval), method statements (proposed approach to a specific construction activity), and engineering calculations for specified design elements. Each type carries a different review cycle — product data may close in two rounds while a complex facade shop drawing set may take five or six.

The Submittal Register: Your Single Source of Approval Truth

The fundamental problem on most GCC sites is that submittals live in email inboxes. The PM knows the chiller was "sent weeks ago." The MEP coordinator thinks it came back with comments. Nobody has the revision number, the response date, or the approval status in one place.

A submittal register solves this. For each entry it needs to track:

Submittal reference number — unique, per contract package
Description — what material or method, and which specification clause
Revision — A, B, C through each revision cycle
Date submitted and response required by — calculated from the contract review period
Date response received and approval status — Approved / Approved as Noted / Revise and Resubmit / Rejected
Procurement lock — can this material be ordered? Yes or No based on approval status
Installation lock — can this activity proceed?

For a SAR 200M project, you will typically manage 300 to 600 submittals across structural, architectural, MEP, civil, and specialist subpackages. Without a register, open approval status becomes invisible, and site teams fill the vacuum with informal verbal sign-offs — and that is precisely where the SAR 780K replacement cost originates.

Managing Revision Cycles Without Losing Track

Most submittals are not approved on the first submission. The consultant reviews, marks up with comments, and returns the package. The contractor addresses the comments and resubmits at the next revision level. This is normal and expected — it is why the register tracks revision letters, not just submission dates.

What goes wrong without version control:

Wrong revision in the field. The site team receives Rev. B but is still building to Rev. A because nobody updated the current-drawing register.
Comments addressed partially. Rev. B addresses comment 3 but misses comment 7 because the original comment log was not maintained per revision.
Consultant loses continuity. Without the full revision history attached to the submittal record, the engineer reviewing Rev. D cannot recall what Rev. B said — and may inadvertently approve something contradicting an earlier response.

Each revision needs to be attached to the original submittal record, with the comment log from the previous round embedded. When the engineer reviews Rev. C, they should be able to see their comments on Rev. B and how the contractor responded to each point.

This matters commercially too. Revision cycles take time. If the consultant first review returns "Revise and Resubmit" on day 28 of a 21-day review period, and the contractor resubmits on day 35, and the second review takes another 21 days — that is 56-plus days on a submittal the schedule assumed would close in 21. The delay record in the submittal register is contemporaneous evidence for an EOT claim under FIDIC Clause 20 if that approval sequence sits on the critical path.

The Procurement Lock: Do Not Order Until Approved

This is the hardest discipline to enforce on GCC sites, because procurement timelines create pressure. Long-lead items — chillers, generators, curtain wall systems, specialist precast — often need to be ordered 16 to 26 weeks before their installation date. That order date frequently falls before the submittal process has completed.

The result: procurement orders the equipment to protect the programme, the submittal returns "Revise and Resubmit," and the contractor is now holding SAR 2 to 8M of unapproved material with limited options.

The right approach is to start submittals earlier — but that requires submittal lead time to be built into the procurement schedule from the beginning. For each long-lead item:

Identify the required-on-site date from the construction programme
Back-calculate the order date: fabrication plus delivery lead time
Back-calculate the approval-required date: before the order date
Back-calculate the submission date: approval-required date minus the contractual review period

If that submission date falls before design information is available, that is a programme risk to flag and escalate — not a procurement shortcut to take. In a properly configured submittal management system, the procurement lock is binary: if the latest revision status is not "Approved" or "Approved as Noted," procurement cannot raise a purchase order against that item. This single rule prevents the SAR 780K scenario.

Response Time Management: Know Your Contractual Clock

FIDIC-based contracts require the engineer to respond to submittals within a defined period. On Saudi Aramco projects, standard review periods are 14 calendar days for straightforward product data and 21 days for shop drawings. NEOM and ROSHN contracts have their own templates — but all of them share one important characteristic: the review clock starts when the submittal is formally received and logged, not when it was emailed.

This matters in two directions.

For claims: if the engineer exceeds their review period and causes a programme delay, the contractor has an entitlement to EOT and potentially prolongation costs — but only if the submission date and response date are clearly documented. An email thread where the exact received date is disputed does not constitute a contemporaneous record.

For requests: if the contractor submits with insufficient documentation, the engineer can return it as "not accepted for review," resetting the clock. The 21-day period does not start until the submittal package is complete. This is how consultants avoid being responsible for a delay caused by an incomplete first submission.

A submittal register makes the clock visible to both sides. Consultants managing their own review pipeline can see what is overdue in their queue. Project managers can chase two days before a review period expires rather than three weeks after — the difference between a proactive commercial record and a reactive dispute.

What Good Submittal Management Looks Like

For a GCC contractor running a structured submittal process, the benchmark looks like this:

All submittals across packages are in one register, visible to the PM, QS, procurement manager, and subcontractor coordinators in real time
Long-lead submittals are submitted 8 to 12 weeks before the procurement decision date, not after the order deadline has passed
No purchase orders are raised against materials with open or rejected submittal status
Revision history is attached to each record — consultant comments in, contractor response, new revision submitted — so the complete audit trail is in one place
Contractor submission dates and consultant response periods are monitored with automatic overdue alerts before the contractual deadline, not after
The register serves as the claims evidence base from day one: every submission date, every response, every delay is documented contemporaneously

The difference between a project that handles 15 rejection cycles without programme impact and one that loses 11 weeks to a single resubmission is not luck. It is the discipline to manage submittals as a planned, tracked workflow rather than a background email activity.

Five Practical Starting Steps

Audit your current submittal status today. Build a list of every open approval, its current revision, and its required-on-site date. The gap between expected and actual completion is your exposure.
Define procurement locks immediately. For every long-lead item with an open submittal, flag the purchase order as on hold until approval is received.
Build the submittal schedule into the programme. For every long-lead item, back-calculate the submission date from the required-on-site date and add it to the schedule as a predecessor activity.
Create one register for all packages. Centralise structural, architectural, MEP, and specialist submittals — even if different coordinators own each section.
Set overdue alerts before deadlines, not after. A notification at day 18 of a 21-day review period gives you three days to chase. A notification at day 25 is a post-mortem.