Engineering Document Control Software: Why the As Built Register Never Matches What Got Installed

Why document control fails at exactly the moment it matters

A pipe spool arrives on site. The fabricator built it to isometric revision C. Revision D was issued three weeks earlier because a nozzle orientation changed, and the transmittal went out, and the fabricator's document controller received it and filed it, and the shop foreman never saw it because the drawing on the shop floor was printed in February. The spool does not fit. Somebody now pays for the rework, and the argument about who pays takes four weeks and involves lawyers reading transmittal logs.

Everyone in that chain had a system. The engineer used ProjectWise. The owner used Aconex. The contractor had Meridian. The vendor used a folder on a server called DRAWINGS_FINAL. Each of those tools is competent at its own job, and none of them can tell you the one thing that mattered: does the latest issued revision of this document exist, acknowledged, in the hands of the party who is building from it right now. That question crosses organisational boundaries, and every packaged system is built to be authoritative inside one organisation.

The other place it fails is handover. The contract says the owner receives a complete as built document register aligned to the asset tag structure, and a payment milestone hangs on it. Six weeks before handover somebody opens the register and finds 340 vendor documents that were never received, several hundred documents whose numbers do not map to any tag, and an unknown number of drawings marked as built that were never updated after the last field change. The project team then spends two months doing archaeology, and the owner's maintenance team inherits a document set they do not trust for the next thirty years.

Problem 1: every party numbers documents differently and all of them are right

The owner has a corporate document numbering standard baked into their asset management system. The engineer has a project numbering scheme from their own procedures. Each equipment vendor numbers to their own factory standard and will not change for your order. Contractors use whatever the subcontract says. So the same heat exchanger data sheet exists under four numbers, and the cross reference lives in a spreadsheet maintained by one document controller.

Packaged systems impose a metadata model. SmartPlant Foundation and ProjectWise are both configurable, genuinely, but configuration means fitting your project into their structure, and each new project with a different owner standard means reconfiguring or accepting a compromise. The compromise becomes a workaround, the workaround becomes a spreadsheet, and the spreadsheet is the thing that fails at handover.

What a custom build does: treat document identity as a set of aliases against one internal record. The owner number, the engineer number, the vendor number and the contractor's subcontract reference all point to the same document object, and any of them resolves in search. Numbering rules are defined per project as a composable scheme, so a new project standard is configuration by a document control lead rather than a development ticket. This sounds administrative. It is the single reason handover reconciliation takes two months, and fixing it changes the shape of the project's last quarter.

Problem 2: revision status is not one field

A document has an issue revision, an issue purpose such as for review, for approval, for construction or as built, a review comment status returned by each reviewer, and a hold point that may block it regardless of the other three. Different parties use different codes for the same thing, and a document issued for construction by the engineer may still be under a client hold that the site does not know about.

What a custom build does: model revision, purpose and status as separate dimensions with an explicit state machine, and make the current construction issue an unambiguous derived fact rather than a human interpretation. The site view then answers exactly one question well: for this area, what may I build from today. Every superseded revision is retained and marked, and the system can produce, for any date in the past, the set of revisions that were current on that date. That capability is what settles a rework dispute in an afternoon instead of a month, and it is worth building on that basis alone.

Problem 3: review comments arrive from five reviewers in five formats

The owner's process engineer marks up a PDF. The operations representative sends an email with a numbered list. The safety reviewer uses a comment sheet template. The engineer receives all of it and has to consolidate, resolve conflicts between reviewers who disagree, respond to each comment, and reissue. On a large project that is thousands of comments per month, and the response record is the evidence that the review actually happened.

Aconex and Newforma both handle transmittals and correspondence well and are strong at the audit trail. Where teams still fall back to spreadsheets is comment consolidation and disposition, because that step requires merging comment sets, detecting contradictions, assigning responses and closing each comment individually against a reissue.

What a custom build does: a comment object with an author, a code, a location on the document, a disposition and a responder, collected from PDF markup, email and uploaded sheets into one review round. Conflicting comments on the same location are surfaced to the lead engineer before response drafting rather than after reissue. Text extraction genuinely helps here: converting emailed comment lists and scanned comment sheets into structured comment records is repetitive work that a model does well, with a review queue for anything ambiguous. Do not let it write dispositions. That is engineering judgement and it carries liability.

Problem 4: vendor documents are late and nobody is chasing them

Every purchase order carries a vendor document requirement list: general arrangement drawings, data sheets, test certificates, operating and maintenance manuals, spare parts lists, each with a due date relative to order placement or delivery. Those documents are contractually required and are usually the largest single gap at handover, because the vendor has been paid and has lost interest.

What a custom build does: generate a document requirement register per purchase order at award, with due dates, expected revisions and the review cycle each one needs. Expediting becomes a report of overdue vendor documents by supplier with the commercial lever attached, meaning the retention or milestone payment that is conditional on submission. Link that register to the tag structure so a completeness view shows, per system, which equipment has a full document set and which does not, months before handover rather than weeks. Owners fund these builds specifically for this feature more often than for any other, because it converts a contractual right into an operational one.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the document register with alias based identity, the numbering and revision engine, transmittals with acknowledgement tracking, distribution matrices and the vendor document requirement register runs $70,000 to $160,000 and ships in 14 to 18 weeks. A full platform adding multi party review rounds with comment consolidation and disposition, hold point management, tag register reconciliation, handover completeness dashboards, site and offline access, and integration with the engineering and asset systems runs $200,000 to $500,000 phased over 8 to 14 months.

What pushes the number up: integration with an engineering data warehouse or a tag register held in a plant design system, because the reconciliation logic is where the value is and it is not trivial. Migration of legacy projects, especially scanned drawings where title block extraction is required to rebuild the register. Handover data standards, if the owner requires structured information deliverables rather than a document set. And a genuine offline mode for remote sites, which is a real engineering effort rather than a checkbox.

What keeps it down: launching on one live project with one owner standard, and treating the second project's standard as the test of whether your numbering engine is actually configurable. Two projects is the honest proof. One is a demo.

Build versus buy, and when the packaged systems are right

Buy if you are running one project at a time with a stable delivery model and an owner who has no strong document standard of their own. 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. Buy also if your organisation is the engineer on someone else's project and the owner has already mandated a system, because then your job is to work inside it rather than beside it.

Build when two or more of these are true. First, you are an owner running a programme of capital projects and every project reconfigures a packaged system to your standard again. Second, your handover register reconciliation is a manual exercise that consumes months. Third, vendor document expediting is done in a spreadsheet by one person. Fourth, you have paid for rework caused by construction from a superseded revision and could not quickly prove who held what. Fifth, your document numbering must map into an existing asset management system whose structure the packaged tool cannot represent without compromise.

The argument for building is not features, because the packaged systems have more features than you will use. It is that document control on a capital project is fundamentally a reconciliation problem between organisations that each have their own valid conventions, and a product that requires everyone to adopt one convention will be worked around by whichever party has the most commercial leverage. A system you own can absorb their conventions instead of fighting them.

How to choose a developer for engineering document control software

Ask them how the same document can carry four numbers. If the answer is one identifier and a comments field, they will build a file share with metadata and you will be back to a cross reference spreadsheet within one project.

Ask how they would produce the set of current revisions as at a date eight months ago. This is the question a dispute turns on, and it forces the developer to describe an append only history rather than a mutable status field. If they hesitate, they have not built a controlled system before.

Ask what they have integrated on the engineering side. A tag register from a plant design system, an asset register in a maintenance system, and a purchase order feed from an ERP (Enterprise Resource Planning) are three different problems, and vendor document requirement generation depends on the third. Ask for the named systems and what actually flowed.

Ask who owns the code and settle it before kickoff. You should hold the repository, the cloud accounts and the right to bring in any other firm. At Digital Heroes the client owns the code from the first commit. A document control system outlives the project it was built for, and you should not be renewing a licence with a firm that holds your project record hostage.