Document control

What exists, at which revision, in which status, issued to whom and on what date — and what each issue superseded.

Sample model. Not a Seimora project. Lit: the pieces on grid 1 that DEMO-SEI-ZZ-XX-DR-S-0001 draws, at P02; P01 is kept as superseded, not deleted. Drag to rotate, pinch or use the buttons to zoom. Click a member.Loading the sample model.

Document control is the part of a project nobody wants until the week they need it, and then it is the only part that matters. Most disputes about a construction job reduce eventually to one question: what did this party hold, and when did they get it. A register answers that in a line. Recollection, an email thread and a shared folder with nine hundred files in it answer it with an argument.

Four facts about every document

A document is under control when four things about it are known and none of them is in somebody's head. Its number, which is what makes two files the same document. Its revision, which is what makes two documents different. Its status, which is what a reader is allowed to do with it — issued for comment, for construction, for fabrication, superseded. And its distribution, which is which party holds which revision at this moment. The fourth is the one that is routinely lost, and it is the one that matters most: a register recording what was issued but not to whom answers the wrong half of the only question anybody ever asks, which is never "what revision exists" but "what revision did they have".

A transmittal is the evidence, not the courtesy

An email with attachments is a delivery with no record of itself. A transmittal is the record: a reference of its own, the date, the sender, the named recipients, every document in the package with its revision and status, what each one supersedes, and what the recipient is being asked to do with it. It exists so that the answer to "when did you get this" is a document rather than a search of somebody's mailbox, and so that a package cannot be half-received without that being visible. Writing one costs a few minutes. Not having one costs nothing at all until it costs everything, once, late, in front of parties who are already unhappy.

Superseded, and kept

Deleting a superseded revision looks like tidiness and is the most expensive habit in this discipline. What was built was built to a revision, and proving what that revision said is impossible once only the current one survives. So a superseded document is retained and marked as superseded — watermarked, moved to a superseded set, or flagged in the register, whichever the project's system supports — and the register names what replaced it and on what date. The same rule is why a drawing is never reissued under its old revision with a small change in it: two different documents sharing one identity is the failure this whole discipline exists to make impossible. How a revision is marked and issued on the engineering packages is set out once under revision control.

Registers of questions, and of packages

The same four facts govern the two registers a job argues about most. A question raised against a document needs its own number, the drawing and revision it was raised against, the party it was put to, the answer, the date, and the revision that carried the answer back into the documents. A package sent for another party's review needs what was sent and to whom, on what date, what status came back, and whether the resubmission is the same document at a new revision. Neither is a separate discipline. A question and a submittal are documents with a loop attached, and they fail in the same way: a reply that never reached the drawing it was about.

Whose system it lives in

A register lives in whatever the project already runs — a common data environment a client or a contractor operates, a document system inside one party's own business, or, more often than anyone admits, a spreadsheet issued as a controlled document in its own right. None of those is hosted here, and no connector to one is in service: the connectors that exist for them are labelled roadmap rather than built, on integrations. That is a smaller constraint than it sounds, because control is a property of the register rather than of the software. What decides whether a job has document control is whether one named party is answerable for the four facts above, and whether every other party knows which one that is.

Pending confirmation

Each of these is held until a fact is confirmed, and named here rather than written around.

HELD — NOT PUBLISHED

The register this work keeps is not published as something you receive. It is one of the documents held behind the commercial boundary around this practice, and it is held for the same reason the rest are: what a register has to carry, and which parties return the entries in it, depend on whether this work runs inside the project's own system or beside it. What is held is the assembled register and its index, not the transmittals, the distribution list and the superseded set above — those exist on a job whether or not anybody keeps a register. The bands below describe how one is kept regardless.

What you receive: A numbering, revision and status convention: how a document is identified, how a revision is marked, and what each status permits a reader to do
A transmittal per issue: what was sent, to whom, on what date, at which revision, and what each document supersedes
A distribution list per document class: which parties receive it, and in what form
A superseded set, retained and marked as superseded rather than deleted
What you supply: The numbering, revision and status conventions the project already runs, where it has any
The parties who receive each class of document, and a named recipient in each
The system the project's documents are kept in, and what access this work is given to it
Which party is answerable for the register, where that is not this one

Continuous line: Seimora’s scope Dashed line: By others

Which packages a job’s files can be exchanged with, and in what form, is set out once on the standards page.

What leaves

Hands on to: Project controls
The transmittal record and the revision status of every issued document go to project controls, so a document milestone is reported against what was actually issued and received rather than against what was expected to be.
Hands on to: Closeout documentation
The register at its final state, and the transmittal record behind it, go to closeout documentation, so the closeout set is indexed against what was issued rather than against what somebody remembers issuing.

Start with this work

Send the model or the drawing set and say which of it you want. A single page of scope is a normal way to start; the other practices are there if the job needs them later.

Discuss Your Project