Submittal Management Best Practices for Capital Projects

Submittal management best practices for capital projects mean planning, submitting, routing, reviewing, approving and archiving every required item through one controlled, auditable workflow. The process should connect each submittal to its specification section, responsible reviewer, contractual response period, project schedule activity and related RFI, drawing or change. A document controller should be able to see what is due, who owns the next action, which items are overdue and what status was valid at each point in time.

What Submittal Management Best Practices For Capital Projects Means in Practice

Submittals include shop drawings, product data, samples, method statements, test certificates, inspection records and O&M information. Best practice is not simply keeping a register of PDFs. It is a governed information exchange that supports design compliance, procurement, construction sequencing, quality control and handover.

This distinction is often misunderstood because the visible task is administrative: create an item, attach a file and send it for review. The project consequence is much wider. A submittal may control the release of a long-lead item, the start of fabrication, an inspection activity or a critical-path installation. Its status may also become evidence in a time or cost claim.

ISO 19650-1:2018 and ISO 19650-2:2018 establish the importance of information requirements, responsibility matrices, controlled workflows and a common data environment. Status codes must be unambiguous. A project may use codes such as S1, S2 and S3 or approval codes such as A, B and C, provided the project defines what each means and applies them consistently.

Contract requirements must sit alongside the information standard. FIDIC Red Book 2017 includes provisions relevant to delayed drawings and instructions, while project specifications commonly set response periods such as 14–21 days for engineer reviews. The workflow therefore needs to show both the contractual deadline and the actual response history.

Why This Matters for Document Controllers & Project Coordinators

Document controllers are the first operational control point for information quality. They check whether a submission is complete, correctly identified, correctly versioned and routed to the right reviewer. They also maintain the authoritative history when a submittal is returned, revised and resubmitted.

• Document controllers maintain unique IDs, file versions, status codes, transmittals, review dates and the final record.
• Project coordinators connect submittal dates to procurement, construction sequencing, progress reporting and risk registers.
• Reviewers and approvers provide technical decisions within the period defined by the contract or project procedure.
• Owners and PMCs need portfolio-level visibility of information risk, not just a list of closed documents.

The scale makes control material. The Navigant Construction Forum review of more than 1,300 projects reported an average of 796 RFIs per project, a range from 10 to 48,000 and an average response time of 9.7 days against common requirements of 7–10 days. It estimated a median review and response cost of $1,080 per RFI and found that about 22% were not valid because clearer information could have avoided them. These figures concern RFIs rather than submittals, but they show why information exchanges require an operating process rather than informal chasing.

GIRI’s The Cost of Error (2015) estimates that avoidable errors cost the UK construction industry 21% of project cost on average, including direct, indirect and unrecorded costs. The figure is not attributable solely to submittal management. It does show the exposure created when incorrect, incomplete or late information reaches downstream work.

Submittal histories also support claims analysis. AACE International Recommended Practice 29R-03 identifies RFIs and submittals as corroborating evidence in forensic schedule analysis. A defensible record includes the unique ID, specification reference, submission date, response date, responsible reviewer, status history and relationship to the relevant schedule activity.

The Traditional/Manual Approach — and Where It Breaks Down

A common manual sequence starts with a contractor or coordinator building a register in Excel from the specification. The document controller checks the file, sends it by email, receives comments or a marked-up PDF, then re-enters the status and dates in the register. Shared drives hold attachments, while separate email threads hold much of the decision history.

This can function on a small, stable package. On a capital project with multiple firms and disciplines, the control points become fragile.

• Competing registers: the contractor, consultant and owner may each maintain a different count, status or due date.
• Manual transcription: an incorrect ID, revision, specification section or reviewer can send the item into the wrong workflow.
• Hidden ageing: a spreadsheet may show an item as open without showing how long it has waited at each review node.
• Uncaptured decisions: an approval in email or chat may never enter the formal record.
• Weak schedule connection: long-lead and critical-path submittals are treated like routine documents.
• Limited bottleneck analysis: overall averages conceal a structural steel, façade or MEP controls discipline whose reviews consistently exceed target.

The result is often discovered late: procurement cannot release an item, the field is working from an unclear revision, or a claim requires reconstruction of who had what and when. A manual log is not automatically inadequate; the problem is using an uncontrolled log, email and storage arrangement as the project’s only evidence.

Step-by-Step Framework

Step 1 — Assess current state

Start by mapping the actual workflow, not the procedure written in the project execution plan. Identify where the register lives, where files are stored, how reviews are routed and how final statuses are recorded. Interview three to five reviewers, project managers or coordinators to locate friction that the register does not show.

Establish a baseline using open, closed and overdue items. Capture average review cycle time from submission to final status, the percentage responded to within the contractual timeframe, resubmittals requiring two or more cycles, and overdue backlog by discipline and reviewer. Also assess the quality of the initial register:

• What percentage of items maps to a specification section?
• What percentage links to a WBS or schedule activity?
• Are long-lead items dated against procurement milestones?
• Are status codes and naming conventions used consistently?
• Which disciplines have the longest cycles or highest resubmittal rates?

Do not invent a universal submittal volume benchmark. The dossier identifies no statistically robust public average for submittals per project. Use the project’s own register as the baseline.

Step 2 — Define standards, templates & governance

Write the responsibility matrix before configuring the workflow. Define who creates the item, who performs the document-control preflight, who reviews it, who approves it, who can return it and who closes the record. Set escalation responsibility when a reviewer has not acted within the agreed period.

A useful register contains a unique ID, title, specification section, discipline, submittal type, WBS or schedule ID, planned submission date, actual submission date, contractual response deadline, actual response date, reviewer, status history, related RFI, related change and final disposition. Add procurement or installation milestones where the item controls release or workface readiness.

Define statuses in writing. For example, A may mean Approved, B Approved as Noted, C Revise and Resubmit and D Rejected or Not Approved. The exact code set is project-specific; the critical requirement is that a field team can tell whether fabrication or installation is authorised. Align the project’s information status approach with ISO 19650 principles where appropriate.

Set naming and revision rules such as project code, discipline, submittal ID and revision/date. Establish one authoritative register and one approved location for the current file. A multi-step sequence may be contractor quality check, document-controller preflight, lead technical review, secondary review and final approval. An escalation trigger at 75% of the allotted review period is a practical governance rule, but it should be agreed in the project procedure rather than assumed to be contractual.

Step 3 — Select & implement supporting technology

Evaluate technology against the workflow you have defined. The core requirement is a common data environment with controlled access, configurable routing, defined statuses, a complete audit trail and reporting. Useful capabilities include bulk creation or import of a register from specifications, links between submittals and drawings or RFIs, deadline notifications and dashboards filtered by discipline, reviewer and age.

Test whether the system preserves history during migration from Excel, email and shared drives. A current status without the earlier submissions, responses and revisions is not a complete record. Also check integration with schedule, procurement, cost and quality systems, together with security and compliance requirements for public or regulated projects.

AI can support specific control tasks. It can propose a draft register by extracting specification sections, paragraphs and required submittal types; suggest a reviewer based on discipline and configured governance; identify duplicate or related items; and connect a submittal to relevant RFIs, drawing revisions or issues. These suggestions need human validation, particularly where the result affects approval, procurement or compliance.

Step 4 — Roll out, train and monitor adoption

Begin with one building, package or discipline rather than changing every workflow at once. Use the pilot to test register fields, status definitions, notifications, escalation rules and the quality of incoming submissions.

Train each role on its actual task. Document controllers need register, version, audit and dashboard training. Reviewers need a clear method for comments, markups, decisions and due dates. Subcontractors need a submission checklist covering file naming, references, revision, completeness and related specification requirements.

Review adoption weekly during rollout. Track new items created versus items formally logged, overdue items, resubmissions and the percentage that follows the agreed workflow rather than email. A short guide should explain where the authoritative file sits, which status permits the next action and how an urgent issue is escalated.

Step 5 — Measure impact against baseline KPIs

Compare the same measures captured in Step 1. The most useful indicators are average review cycle time, percentage of responses within the contractual period, resubmittal rate, overdue backlog and performance by discipline and reviewer.

Public guidance commonly cites 10–14 days for design-team responses, with shorter periods on some fast-track work, while internal owner targets often seek at least 90–95% on-time responses. Treat both as reference points, not universal standards: the contract and project procedure govern. Multi-cycle items can double or triple effective cycle time, so report both first-pass response and total time to final status.

Common Mistakes to Avoid

Calling the register an administrative spreadsheet. It is also a contractual, schedule and claims record. Preserve status history, relationships and timestamps.

Skipping the document-control preflight. Reviewers should not spend technical review time correcting missing references, wrong revisions or incomplete packages. A preflight checklist should precede technical routing.

Using inconsistent statuses. “Approved with comments”, “reviewed” and “approved as noted” may have different practical meanings. Define one controlled vocabulary and the action permitted by each status.

Allowing informal approvals to sit outside the record. Decisions made in email or chat should be captured in the formal workflow with the relevant reference and date.

Ignoring long-lead and critical-path items. A submittal for equipment linked to procurement cannot be prioritised in the same way as a non-critical catalogue item. Link both to the relevant schedule or procurement activity.

Reporting only a project-wide average. Slice cycle time and resubmittals by discipline, specification division and reviewer. A single persistent bottleneck requires a targeted response.

Maintaining multiple authoritative logs. The contractor’s, consultant’s and owner’s working views may differ, but the project must define one authoritative record and reconciliation method.

How AI-Native Platforms Like Zepth Change This Workflow

An AI-native common data environment applies intelligence within the information workflow rather than treating AI as a separate add-on. The operating principle remains controlled human approval: AI can identify, compare, route and flag; a responsible person signs off anything consequential.

For submittals, that means extracting a draft register from specifications, including the section, paragraph, submittal type and supporting references, for a document controller to validate. It can suggest routing from discipline and project governance, identify related RFIs and drawing revisions, and flag a long-lead item whose review window is compressed against the procurement or construction sequence. Natural-language search can help a coordinator find all records related to a system, location or specification reference across the CDE.

Zepth is built around a CDE connecting documents, RFIs, submittals, project controls, procurement, quality and risk. Zepth Core for documents, RFIs and submittals provides the project workflow context. Zepth Vector procurement workflows can connect approved information to tendering, contracts and long-lead purchasing. Where a design decision affects budget or CapEx, Zepth Edge asset and financial controls provides the related cost and reporting context.

Zepth AI reviews project information against drawings and specifications, supplies confidence-scored findings and surfaces relevant references. The document controller remains responsible for validating the source, resolving ambiguity and ensuring that the approved status is recorded correctly. That combination addresses the manual failure points without removing the governance required on an owner-side capital project.

The practical test is not whether a platform has an AI label. It is whether the team can move from specification to register, from register to accountable review, and from review to an auditable decision while retaining the links to schedule, procurement, cost and handover.

FAQ (schema-marked)

For a project-specific framework and checklist, book a walkthrough and subscribe to Zepth Insights for practical project-controls guidance.