Engineering Document Control Software Problems: The 7 That Cost You Rework and Handover, and How to Avoid Them

Why does the document register scope keep producing a file share?

The brief usually describes storage with structure. We need a register, folders by discipline, metadata, permissions and a transmittal log. Every one of those is legitimate, and a system built to that description is a file share with metadata, which is what most projects already have and what most projects work around.

The workaround is always the same shape. Because the system holds one identifier per document, and the owner, the engineer, each vendor and each contractor all number to their own valid standards, somebody maintains a cross reference spreadsheet. That spreadsheet is the real register, it lives on one person's machine, and it is what fails at handover when the same heat exchanger data sheet turns out to exist under four numbers with no reliable link between them.

The fix is to treat document identity as a set of aliases pointing at one internal record. The owner number, the engineer number, the vendor's factory number and the contractor's subcontract reference all resolve to the same object, and any of them works in search. Numbering rules are defined per project as a composable scheme that a document control lead can configure, not a development ticket.

Ask any prospective developer how the same drawing carries four numbers. If the answer is one identifier and a comments field, you are buying storage, and you will be back to the cross reference spreadsheet inside one project. The alias model sounds administrative and it is the single reason handover reconciliation takes two months instead of two weeks.

What goes wrong when you migrate legacy project documents?

Migration here is rarely a file copy, because the register you need does not exist in the files. On live projects you inherit a mixture of native documents, issued PDFs and scanned markups, with the authoritative revision determined by a naming convention that changed twice.

Three specific problems recur. First, the register and the files disagree. The register says revision D was issued, the folder contains C and E, and nobody can say whether D existed or was skipped. Second, scanned drawings carry their real metadata in the title block rather than in a database, so rebuilding a register from an archive means reading title blocks, which is a real workstream and should be budgeted as one. Third, as built status is asserted rather than evidenced. Drawings marked as built were often never updated after the last field change, and importing that status uncritically means your new system now confidently states something untrue about the asset.

The approach that works is to migrate the current issue set with evidence, meaning the revision plus the transmittal that issued it, and carry everything else into a searchable archive without asserting status it cannot support. Where as built status cannot be evidenced, mark it unverified and let the project close that gap deliberately. An owner relying on this set for thirty years is better served by an honest unverified flag than a confident label nobody can substantiate.

Why do tag register and purchase order integrations break after launch?

The integrations that give this category its value are the ones connecting documents to the plant. A tag register from the plant design system, an asset register in the maintenance system and a purchase order feed from the enterprise system are three separate problems, and vendor document requirement generation depends entirely on the third.

They break in predictable ways. The tag register is reissued as the design develops, tags are renamed or split, and documents linked to the old tags quietly become orphans that no completeness report counts. Purchase orders get amended, scope is added by variation, and if the requirement register was generated once at award it never learns about the extra equipment. Asset naming conventions differ between the design system and the maintenance system, so a mapping built during commissioning drifts as operations renames things for their own reasons.

The fixes are ordinary discipline applied consistently. Treat tag changes as events that must be reconciled rather than as a fresh import, with a queue of orphaned links that somebody owns. Regenerate document requirements on purchase order amendment, not only at award. Hold the mapping between design and maintenance naming as versioned data with an owner, and reconcile it on a schedule rather than assuming it holds.

When selecting a developer, ask what they have integrated by name and what actually flowed. The reconciliation logic between documents and tags is where the value of the whole system sits, and a team that has only moved files between folders will underestimate it badly.

What happens when vendor documents and hold points are not covered?

Vendor documentation is the largest single gap at handover on most projects, and the reason is commercial rather than technical. The general arrangement drawings, data sheets, test certificates, operating manuals and spare parts lists are contractually required, and by the time anyone chases them properly the vendor has been paid and has lost interest.

Systems that treat vendor documents as ordinary incoming documents cannot help with this, because they only know about documents that arrived. What you need is a register of documents that should exist: generated per purchase order at award, with due dates relative to order placement or delivery, the expected revisions and the review cycle each one requires. Then expediting becomes a report of overdue documents by supplier with the commercial lever attached, meaning the retention or milestone payment conditional on submission, months before handover rather than weeks.

Hold points fail differently and more dangerously. A document can sit at revision D, issued for construction, with an outstanding client hold that blocks it, and if status is modelled as a single field the site sees issued for construction and builds. Revision, issue purpose and review status are three separate dimensions, and the site view must derive one unambiguous answer to one question: what may I build from in this area today. Anything requiring interpretation will eventually be interpreted wrongly, under time pressure, by someone who is not a document controller.

Should you build custom or configure what you already own?

If you are running one project at a time with a stable delivery model, buy. Aconex, ProjectWise, Meridian and Newforma are mature products with real deployment expertise available, and a competent configuration by an experienced document control lead will serve you well. Features are not the constraint, and a custom build on a single project spends capital on something the market already solved.

Buy also if you are the engineer on someone else's project and the owner has mandated a system. Your job then is to work inside it rather than beside it, and running a parallel register against a mandated platform creates two versions of the truth and a commercial argument you will lose.

Before commissioning anything, test whether your complaint is the tool or its setup. A great deal of what gets blamed on Aconex or ProjectWise is a distribution matrix that was never maintained, a numbering scheme agreed late, or a review workflow nobody enforced. Those are fixable inside the product by someone who knows it, for a fraction of a build.

Build when the pattern is structural and repeating. You are an owner running a programme of capital projects and every project reconfigures a packaged system to your standard again. Handover reconciliation against the asset tag register is a manual exercise measured in months. Vendor document expediting runs on one person's spreadsheet. You have paid for rework from a superseded revision and could not quickly prove who held what. Or your numbering must map into an asset management structure the packaged tool cannot represent without compromise.

How do hidden costs get into the quote?

The first is engineering system integration, which is where the value is and is regularly quoted as a single line. A tag register held in a plant design system, an asset register in a maintenance system and a purchase order feed are three separate efforts with three separate reconciliation problems. Ask for them itemised and named.

The second is legacy migration, particularly scanned archives where title block reading is required to rebuild a register. That is its own workstream with its own quality assurance, and folding it into a build estimate hides it until it is late.

The third is handover data standards, since an owner requiring structured information deliverables rather than a document set is asking for a different deliverable model, and that needs to be in scope from the start.

The fourth is genuine offline access for remote sites, where users need documents available and a way to record what they used, which is real engineering rather than a setting.

The fifth is the second project. A numbering engine is only proven configurable when a different owner standard runs through it, so plan the first two projects as one programme and expect the second to surface assumptions the first did not. A build validated on one project is a demonstration, not a system.

What separates a build that works here from one that fails?

Revision history is append only, so the system can reconstruct the exact set of current revisions as at any past date, with the transmittal that issued each one and the acknowledgement that received it. This is the capability a dispute turns on, and it is the question to ask before signing anything. A developer who hesitates has been building mutable status fields, which cannot answer it at all.

Acknowledgement is tracked as a distinct fact from distribution. Sending a transmittal proves you sent it. What matters commercially is whether the party building from the document received and acknowledged the current issue, and whether the person on the shop floor is working from what their document controller filed. Systems that stop at distribution leave the most valuable evidence uncollected.

Extraction is used where it belongs and kept away from judgement. Converting emailed comment lists, scanned comment sheets and legacy title blocks into structured records removes a great deal of repetitive typing, and it should not write dispositions or decide review outcomes.

And ownership is settled before kickoff. This matters more here than in most categories, because a document control system outlives the project it was built for and the record it holds is the evidence base for claims, insurance questions and maintenance decisions long after everyone involved has moved on.