Megaprojects generate extraordinary volumes of technical documentation. A large-scale EPC contract in energy or infrastructure can easily accumulate 50,000 to 150,000 individual documents over its lifespan — engineering drawings, vendor data, specifications, procurement packages, inspection records, transmittals, and ultimately an As-Built package that must be delivered to the operator at project close-out. Without a structured document control framework in place from day one, these volumes become unmanageable. The consequences are well-documented: approval cycle delays, version conflicts, contractual disputes over document status, and a handover package that is incomplete or rejected.

This guide outlines the practical document control best practices that make the difference between a controlled project and one drowning in document chaos.

Why Document Control Fails on Megaprojects

The most common failure mode is not technical. It is governance. Projects frequently start without a formal Document Control Procedure (DCP) — or worse, with a procedure that exists on paper but is never enforced. Within weeks of project mobilisation, engineering contractors are uploading documents to shared drives, using inconsistent naming conventions, and distributing drawings by email. By the time the project management team realises the extent of the problem, the document register is in a state that requires months to remediate.

Three root causes account for the majority of document control failures on megaprojects:

• Late mobilisation: Document Control is mobilised after engineering has started. The first 400 drawings are already issued before a DCP is approved, a document numbering system is defined, or an EDMS is configured.
• Unclear ownership: The RACI for document control is undefined. Nobody knows who owns transmittal dispatch, who tracks review responses, or who is responsible for maintaining the Master Deliverables Register (MDR).
• Tool without process: An EDMS platform (Oracle Aconex, SharePoint, OpenText) is deployed without governance. The system is live but the workflows, metadata schema, and naming conventions are improvised by each discipline team independently.

The Document Control Procedure (DCP): Foundation of Every Project

The DCP is the primary contractual and operational document that defines how documentation is managed on a project. A solid DCP must address the following in clear, unambiguous terms:

• Document numbering and coding conventions, including project-specific prefixes, discipline codes, document type codes, and revision identifiers
• Document status definitions and their meaning (e.g., IFR = Issued for Review, IFC = Issued for Construction, AFC = Approved for Construction)
• Review and approval workflow: who reviews, in what sequence, within what timeframe, and what constitutes a valid response
• Transmittal procedures: outgoing transmittal format, internal transmittal for inter-discipline review, vendor data transmittal management
• EDMS usage protocols: which platform is used, how documents are uploaded, how metadata is populated, what constitutes the official controlled copy
• Roles and responsibilities: Lead Document Controller, Discipline Document Controllers, EDMS Administrator, Project Engineer for document approval
• Archive and close-out procedures: how documents are moved to final status, how the As-Built package is structured

The DCP should be drafted at project mobilisation, reviewed by the contractor and the client, and issued within the first 4 weeks of project start. Any deviation from this timeline creates risk.

Structuring the Master Deliverables Register (MDR)

The MDR is the project’s single source of truth for deliverable status. It lists every document the project is contractually required to produce, with its current revision, its status, its planned and actual issue dates, and its review response status. On large EPC projects, the MDR can contain 5,000 to 30,000 line items.

A poorly structured MDR is one of the most common causes of handover failure. If the MDR has not been maintained throughout the project — if it was last updated six months before close-out — the final documentation package will contain gaps, and the operator’s acceptance team will reject it.

Best practices for MDR management include:

• Define MDR structure at project kick-off: columns, required data fields, and ownership per discipline
• Integrate the MDR into the EDMS wherever possible, so that document status updates automatically flow into the register
• Conduct weekly MDR review meetings with discipline engineers during peak delivery phases
• Assign MDR maintenance responsibility to the Lead Document Controller, not to the project engineers
• Use the MDR as the baseline for the handover completeness check: every line item must have a corresponding document at final approved status before handover sign-off

For detailed guidance on MDR structure and management, see our dedicated article: Managing the Master Deliverables Register on Engineering Projects.

EDMS Configuration: Getting It Right from Week One

The choice of EDMS platform — Oracle Aconex, Microsoft SharePoint, OpenText Extended ECM, Procore, Dalux, or others — is less critical than the quality of its configuration. A well-configured SharePoint environment will outperform a poorly configured Aconex instance on every dimension: retrieval speed, workflow compliance, and data integrity.

The key configuration decisions that must be made before the system goes live include:

• Metadata schema: What attributes will every document carry? At minimum: document number, title, discipline, document type, revision, status, originator, review due date. These fields must be mandatory and consistently populated.
• Folder and register structure: How is the EDMS organised? By discipline? By work package? By EPC phase? The structure must reflect the project’s actual work breakdown.
• Transmittal and review workflows: For outgoing transmittals to the client or third parties, the workflow must capture: issue date, recipient, response due date, document list, and return response with disposition codes.
• Access rights: Who can upload, review, approve, and supersede documents? Access rights must map to the RACI defined in the DCP, not to the EDMS vendor’s default configuration.
• Integration with procurement: On EPC projects, vendor data management is a major document control workstream. The EDMS must accommodate Vendor Document Requirements (VDRs) and track vendor data submission schedules.

TERADOK’s EDMS Implementation service covers the full configuration scope, from metadata design to workflow setup and user training.

Transmittal Management: Where Projects Lose Time

The transmittal workflow is the operational heartbeat of document control on an EPC project. Every document issued to a contractor, client, authority, or vendor passes through a transmittal. On a large project, the document control team may process 200 to 500 transmittals per month at peak activity.

Common transmittal failures include:

• Transmittals issued without formal response tracking — documents disappear into the client’s organisation with no follow-up
• Inconsistent use of disposition codes (A = Approved, B = Approved with comments, C = Rejected) leading to disputes about whether a document is approved for use
• Missing response due dates, meaning the contractor cannot formally claim document approval delays caused by the client
• Informal distribution by email alongside formal transmittal, creating parallel uncontrolled document flows

Best practice is to make the EDMS the single channel for all formal document exchange, with no exceptions. Informal distribution by email must be explicitly prohibited in the DCP for controlled documents.

ISO 19650 and Information Management on Complex Projects

ISO 19650 provides the international framework for information management in construction and infrastructure projects. Parts 1 and 2 define the principles and requirements for managing information across the project lifecycle, with Part 3 addressing the operational phase. For projects in Europe, the United Kingdom, and increasingly in the Middle East and North Africa, ISO 19650 compliance is becoming a contractual requirement.

The standard introduces a set of governance instruments that directly affect document control practice:

• EIR (Employer’s Information Requirements): The client’s specification of what information they need, in what format, at what level of detail, and on what schedule
• BEP (BIM Execution Plan): The contractor’s response to the EIR, committing to information delivery methods, tools, and processes
• CDE (Common Data Environment): The shared information environment — the EDMS — through which information is exchanged and validated
• MIDP (Master Information Delivery Plan): The schedule of all information deliverables, equivalent to the document control MDR

For a deep dive on ISO 19650 implementation, read our article: Understanding the ISO 19650 Information Management Standard.

Document Close-Out and Handover: The Final Test

The handover package is the moment of truth for document control. If the MDR has been maintained throughout the project, if the EDMS is clean, and if the DCP has been followed, handover is a structured and predictable process. If not, it becomes a crisis.

Handover documentation typically includes three main components: As-Built documentation (drawings and documents reflecting actual constructed conditions), Operations and Maintenance manuals (O&M), and the final document register with all documents at their final status. The operator’s acceptance team will check completeness against the contractual deliverable list, the technical correctness of key documents, and the format and accessibility of the documentation package.

TERADOK’s Final Documentation & Handover service supports project teams through this critical phase, from completeness verification to final package structuring and client acceptance.

Frequently Asked Questions