ARTICLE
Engineering Data Management System
On some projects, the current revision of a drawing is a fact anyone can check in seconds. On others, it is an argument. The difference is not the software. It is whether the data was ever actually managed.
What counts as engineering data
Engineering data is a wider category than most project teams treat it as. It includes the obvious documents — drawings, models, calculations, specifications — and it also includes the schedules that describe them, the registers that track their status, the transmittals that record who received what and when, the RFIs and their answers, and the approval record that says which revision was actually authorized for construction.
Treated as separate, loosely connected things, this collection is where projects lose time: a drawing that references a schedule updated without telling the drawing's author, an RFI answered verbally and never logged, an approval that exists in an email but not in the register. Treated as one connected body of data, with defined relationships between a drawing and the register entry that describes it, engineering data becomes something that can be queried and audited rather than something that has to be reconstructed from memory when a question is asked.
Why folders stop working
A folder structure works, more or less, for a small project with a small team and a short duration, because the number of people who need to remember the convention is small enough that it survives on habit. It stops working at scale for reasons that are structural, not accidental.
- One document, many folders. A drawing belongs conceptually to a discipline, a zone, a package and a revision all at once, and a folder tree can only represent one hierarchy at a time.
- Naming carries meaning that nothing enforces. A file name encodes discipline, zone, type, number and revision by convention, and a convention followed inconsistently is worse than no convention, because it looks reliable and is not.
- There is no single current answer. Local copies, email attachments and folder duplicates all claim to be current, and current ends up meaning whichever copy the person answering the question happens to have open.
- Permissions and history are weak. Anyone with folder access can overwrite a file, and what changed between two versions is rarely visible without opening both and comparing them by eye.
None of this is a criticism of the teams who use folders. It is a description of what happens when a document-centric habit is asked to do a database's job.
What a common data environment actually does
A common data environment solves a specific, narrower problem than its reputation suggests: it gives every information container — drawing, model, schedule, document — one unique identity, one current status, and one location that everyone with permission is looking at, rather than a copy each. That is a real and valuable improvement over folders and email, and it is worth being precise about where its responsibility ends.
A common data environment enforces where information lives and who can see and change it. It does not, by itself, enforce that the information is correct: a wrong dimension uploaded to the right container in the right status is still wrong, just more visibly and traceably so. It does not replace the engineering review that decides whether a design is sound, and it does not replace a defined process for raising and closing out a query. What it removes is the ambiguity about which copy is real, which is a genuinely large source of construction disputes even though it sounds like a small administrative point.
Status, suitability and the audit trail
Status and suitability codes are how a common data environment answers a simple question: can this information be used yet. The distinction between the two is worth being exact about. Status describes where a container sits in its workflow — work in progress, shared, published, archived. Suitability describes what the information inside it may be used for at that point — coordination, review, costing, or construction — and a container can be shared for coordination long before it is suitable for construction.
The audit trail is the record that makes both of those claims checkable after the fact: every status change, every revision, every approval, timestamped and attributed to a person, so that a dispute about what was known and when can be answered from the record rather than argued from memory. On a project without a rigorous audit trail, establishing who approved a change and when takes a genuine investigation. On one with a rigorous trail, it takes a query that returns an answer in seconds — a real difference the first time it matters on a project with any commercial exposure.
Handover: the data the operator keeps
What gets handed over at project completion is decided, in practice, by what was set up to be capturable from the start, not assembled retroactively in the final weeks — and retroactive assembly is where most poor handovers come from. An operator inheriting a completed asset needs the current, as-built model and drawing set; the approval and revision history behind it; the specification and product data for what was actually installed, not what was originally specified; and, increasingly, structured asset information formatted for whatever facilities or asset management system will run the building for the following decades.
ISO 19650's later stages exist specifically to make this a planned deliverable rather than an archaeological exercise: the exchange information requirements defined at the start of the project should already describe what the operator needs at the end, so handover is a defined export from a well-run common data environment rather than a scramble to reconstruct a record that was never kept consistently in the first place.
Getting it right on a live project
None of this is complicated in principle, and most of it fails in practice for the same reason: it was treated as an administrative task assigned to whoever had time, rather than a defined role with the authority to enforce it. A live project needs someone accountable for the register and the common data environment specifically — naming convention, status and suitability discipline, transmittal record — the same way it needs someone accountable for the structural design.
Set up early, with the convention agreed before the first drawing is issued rather than retrofitted once the file count is already in the thousands, engineering data management is close to invisible: questions about current revision, approval status or issue history get answered from the record in the time it takes to look it up. Set up late, it becomes a permanent, low-grade drag on every review, every RFI and every dispute about what was actually issued, and a record everyone increasingly stops trusting.