One Platform, One Project History — Why Document Submittals Cannot Live Apart from the PMIS
By Bassam Samman, PMP, PSP, EVP, GPM · CEO & Chairman, CMCS FZCO
Managing a capital construction project goes far beyond managing document submittals. Cost, contracts, procurement, schedule, risk, quality, health and safety and design all have to be managed through every stage of the project lifecycle. Document submittals, usually handled in Aconex, cannot be managed in isolation from that overall picture. PMWEB brings all of these functions into one fully integrated platform, and it reduces the investment too: one platform to license, implement and support instead of two.
Most owners still run two systems on the same project: Aconex for drawings, submittals and letters, and a PMIS for everything else. Yet every shop drawing, material submittal and method statement is tied to a contract, a cost, a schedule activity, a procurement decision, a design review, a quality check or a safety requirement. Kept in a separate platform, a submittal becomes a file with a status and nothing more. Working on one platform removes the duplicate subscriptions, user accounts, integrations, training and support contracts, and gives everyone the same complete picture of the project.
Infographic 1 – One platform instead of two
This is not a hypothetical scenario. It is a real use case: a major real estate developer in the Gulf region took that step. It retired Aconex for document control and now runs every document submittal, review and letter inside PMWEB. Because its projects had already started on Aconex, it also migrated the complete Aconex history: every document, every revision and every file. New projects need no migration and start directly in PMWEB. This four-part series explains why it matters, how it was done, how projects already on Aconex move their history, and how the same records now feed dashboards and AI. Part 1 makes the case for one platform and one project history. Everything described can be repeated on any PMWEB instance.
Based on real implementations
This series is based on real PMWEB implementations, not a concept: CMCS has migrated two clients from Aconex to PMWEB, including a major real estate developer in the Gulf region. Client names and client data are withheld; the form illustrations and dashboards use sample data.
Is this article for you?
Yes, if your projects manage documents in Aconex, another document management system or a CDE while cost, contracts and schedules are managed somewhere else. This series is written for every layer of the project team and its stakeholders:
Document controllers: keep the Aconex way of working, without double entry and manual tracking (Parts 2 and 4).
PMIS managers: one platform and one database to configure, secure and support instead of two plus an interface (Parts 2 and 3).
Project and programme managers: see a document's status next to its contract, cost, schedule and risk (Parts 1 and 4).
Executives and PMO heads: remove the risk of a split project history and reduce the investment (Part 1).
Contract, cost, design, quality and HSSE leads: work from the same approved documents that drive your own processes (Part 1).
Contractors, consultants and other project stakeholders: one submission platform and one record of every decision (Parts 1 and 2).
Where Document Control Breaks Down Outside the PMIS
A document platform is good at what it was built for: storing files, controlling revisions and distributing transmittals. The problems start when the owner needs to manage the project, not just the documents.
Two records of the truth. A shop drawing's status lives in the document platform, while the contract, the change it triggers and the schedule activity it delays live in the PMIS.
No link to cost and contracts. A rejected material submittal cannot be tied to the commitment, the variation or the payment it affects.
Reporting by spreadsheet. Review turnaround, overdue actions and contractor quality are rebuilt by hand from exports every month.
No asset view at handover. Documents are not coded to the assets that cost, contracts and commissioning are tracked against.
Two sets of licences, accounts and support: for every contractor and consultant.
The High Risk of Two Separate Databases
A statement every owner should weigh
Organisations that manage project documents in Aconex and the rest of their project information in another PMIS are taking a high risk. They separate the history of their project documents from the history of cost, contracts, schedule, risk, procurement, quality and HSSE. Whatever PMIS product they use, if it does not share the same database as their document management, that risk to overall project success remains.
An integration between two platforms does not remove the risk. Interfaces usually pass a status, a number or a link, not the full history of who submitted what, which revision was reviewed, what was commented, when it was approved and what it led to. Each platform keeps its own audit trail, its own users and its own timeline, and the two drift apart over the years of a project.
Claims and disputes. The evidence for a delay or a variation sits partly in the document platform and partly in the PMIS. Rebuilding the story for a claim takes weeks, and gaps weaken the owner's position.
Audit and accountability. No single record shows that a drawing was approved before the work it covers was certified and paid.
Early warning lost. A late review or a repeated rejection is visible in one system, while its cost and schedule impact appears in the other only after the damage is done.
Integration fragility. Every upgrade of either platform can break the interface, and data silently stops flowing.
Incomplete AI and reporting. Dashboards and AI assistants built on either database see only half of the project.
Handover gaps. The asset handover file has to be assembled from two systems with different coding.
Keeping documents and every other project process in one PMWEB database removes these risks at the source: one history, one audit trail and one version of the truth from the first submittal to handover.
Project Delivery Risks of Managing Submittals in Isolation
When document submittals are managed in isolation from the other project management processes, the risk is not only to document control. It reaches project delivery itself: time, cost, quality, safety, claims and handover. The table below sets out the delivery risks we see most often on capital projects that run documents in one platform and everything else in another.
Infographic 2 – Delivery risks when submittals are managed in isolation
Delivery risk
What happens on the project
Impact
How one PMWEB database removes it
Late procurement and construction
A review overdue in the document platform is invisible to the schedule and to procurement. Long-lead orders are placed late and site work waits.
Time
The submittal is linked to its schedule activity and purchase order; overdue reviews show on the same dashboards.
Wrong revision used on site
Inspections, RFIs and work refer to a superseded drawing because site teams cannot see which revision is approved.
Quality, cost
Inspections, RFIs and NCRs reference the approved revision in the same database.
Untracked changes and substitutions
Material substitutions and design changes start as submittals but never reach cost control until the contractor claims them.
Cost
The submittal, the change order and the commitment are linked records.
Missed contractual review periods
Review periods are tracked in one system and contract terms in another, leading to deemed approvals and extension of time claims.
Time, claims
Review due dates come from the contract and are tracked step by step.
Work before HSE approval
Permits are issued and high-risk work starts before the method statement and risk assessment are approved.
Safety
HSSE permits check the approval status of the method statement.
Payment for unapproved materials
Materials on site are certified for payment without an approved material submittal.
Cost, compliance
Payment certification can check the material submittal status.
Weak position in claims and disputes
The evidence for a delay or variation is split across two systems, with gaps and conflicting dates.
Claims
One audit trail from submission to approval, change and payment.
Late warning to management
Reports are assembled by hand from two systems, so problems surface weeks after they start.
Governance
Daily dashboards from one source show overdue reviews and quality trends early.
Incomplete asset handover
As-built drawings, O&M manuals and warranties cannot be matched to the assets tracked in cost and commissioning.
Handover
Every document is coded to its asset from the first submittal.
The bottom line
Each of these risks starts with a document that one part of the project team cannot see in context. Managing submittals in isolation does not only make document control harder; it puts the delivery of the whole project at risk. Keeping submittals in the same PMWEB database as every other process is the most direct way to remove that risk.
Document Submittals Are One Process Among Many
A capital construction project runs on dozens of connected business processes. Document submittals sit in the middle of them: almost every other process either produces a submittal, waits for one, or acts on its outcome. That is why submittals cannot be managed in isolation from site communications, design management, contract and cost management, schedule and risk management, procurement, quality and HSSE management.
Infographic 3 – Document submittals touch every project function
Process area
How it depends on document submittals
Site communications
RFIs, site instructions and inspection requests refer to the approved revision of a drawing or method statement. A submittal comment often becomes an RFI, and an RFI answer often forces a resubmission.
Contract management
Submittals are contract deliverables with contractual review periods. Late reviews and repeated rejections become notices, extension of time requests and claims.
Cost management
Material substitutions, value engineering proposals and design changes start as submittals and end as change orders. Payment for materials on site depends on an approved material submittal.
Schedule management
Each submittal supports a schedule activity. A review that runs over its period delays procurement and construction, and can move the critical path.
Design management
Design deliverables at each stage, design review comments and design changes are submittals. Their status shows whether each design stage can be signed off.
Risk management
Overdue reviews, low first-time approval and long-lead items waiting for approval are early warnings of delay and cost risk.
Procurement management
Purchase orders for long-lead equipment and materials cannot be placed until the material submittal is approved.
Quality management
Method statements, inspection and test plans and material approvals define what is inspected on site. Non-conformance reports trace back to the approved submittal.
HSSE management
HSE plans, risk assessments and method statements for high-risk work must be approved before permits are issued and work starts.
Asset handover
As-built drawings, O&M manuals and warranties are submittals too, and they make up the handover file for each asset.
When submittals live in a separate document platform, every one of these links has to be rebuilt by hand: an RFI log that quotes drawing numbers, a cost report that cannot see why a change order started, a schedule that does not know a review is late. In PMWEB the submittal, the RFI, the change order, the purchase order, the inspection and the schedule activity are records in the same database, linked to the same package, asset and contract. That, more than any single feature, is the reason to move document control into the PMIS.
One platform for every project process
PMWEB manages site communications, design, contracts and cost, schedules and risk, procurement, quality, HSSE and document control on one platform. Moving document submittals into PMWEB completes that picture: the process that touches all the others finally sits next to them.
What One Platform Means for Every Project Stakeholder
The case for one platform is not only a technology decision. It changes the working day of everyone on the project, inside and outside the owner's organisation.
Stakeholder
What it means for you
Document controllers
One place to register, number, distribute and track every document, with no re-keying into a second system and no manual response logs.
PMIS managers
One database, one security model, one set of forms and workflows and one upgrade path, with no fragile interface between two platforms.
Project managers
The status of every submittal beside the contract, cost, schedule and risk it affects, on the same screen.
Programme managers and PMO
Portfolio-wide views of review performance, overdue actions and contractor quality without monthly spreadsheet consolidation.
Contract and cost managers
A change order, claim or payment traced back to the submittal that triggered it, with the full review history as evidence.
Design managers
Design deliverables and review comments tracked against each design stage and its sign-off.
Quality and HSSE managers
Inspections, NCRs and permits that refer to the approved revision, with no doubt about which revision applies.
Contractors and consultants
One platform for submittals, RFIs, variations and payments, with review due dates visible to everyone.
Executives, boards and funders
One version of the truth, a lower total investment and a complete history for audit, claims and handover.
Aconex and PMWEB Compared for Document Control
Capability
Aconex
PMWEB with Aconex-style forms
Document register and revisions
Strong, purpose-built
Adaptive forms with the same fields; Aconex history imported where a project has already started on Aconex
Numbering
Configured per project
Aconex-style pattern that continues the Aconex serials
Review workflow
Document review workflows
Business process workflows with steps, roles, due dates and delegation
Confidential distribution
Mail and distribution lists
Confidential flag plus notified users, enforced in the back end
Link to cost, contracts and schedule
Outside the platform
Same database as commitments, changes, payments and schedule
Asset coding for handover
Metadata only
Asset on every record, shared with cost and contracts
Portfolio dashboards
Exports and separate tools
Power BI dashboards built into PMWEB, reading PMWEB data and displayed within PMWEB
AI across project processes
Sees documents and their metadata
PMWEB AI Assistant (PMWEB-hosted instances) works on submittals together with contracts, cost, schedule, procurement, quality and HSSE data
Deployment
Cloud service only
Cloud hosted by PMWEB, or on-premise on the owner's servers
Licences and investment
A second platform beside the PMIS, with its own subscription, accounts, integration and support
One platform to license, implement and support for every project participant
Key takeaway
Keeping project documents in Aconex while the rest of the project runs in a separate PMIS, even an integrated one, splits the project history across two databases and puts project success at high risk.
Managed in isolation, submittals create delivery risks in time, cost, quality, safety, claims and handover: late procurement, wrong revisions on site, untracked changes, missed review periods, work before HSE approval and weak evidence in disputes.
Managing a capital project goes beyond document submittals. Submittals touch every other function and belong in the same platform, which also means one investment instead of two.
This is proven in practice: CMCS has moved two clients from Aconex to PMWEB.
Next in the series: Part 2 shows the Aconex-style adaptive forms in PMWEB and the back-end logic that makes Aconex users feel at home from day one.
Bassam Samman, PMP, PSP, EVP, GPM, is CEO and Chairman of CMCS FZCO, the PMWEB Authorized Implementation Partner for the GCC and MENA and PMWEB Global Partner of the Year 2025. He has more than 40 years of capital project experience, is a co-founder of the PMI Arabian Gulf Chapter and the author of four books on digitalising project delivery.
