Construction
Architecture and engineering practices
Deliverables by phase, versions that cross, and liability that lasts years.
A practice produces documentation as its product: it does not accumulate it, it delivers it. That changes the problem. What needs controlling is not where a paper is, but which version was delivered, to whom, when, and what was approved from it.
The three controls that matter
| Control | What it prevents |
|---|---|
| Delivered version, with date and recipient | Building from a version that was already superseded |
| Client approvals, by phase | A change being treated as accepted when it was not |
| A record of requested changes | Scope growing unnoticed and unbilled |
Important
The third decides the profitability of the commission. Small changes requested by phone or on site never get billed because nobody noted them, and by project end the practice has done 30% more work than contracted.
How to organise it without bureaucracy
- 1
One file per project, with real phases
The ones you use and invoice, not a textbook's.
- 2
Each delivery recorded as a delivery
Which version, to whom, when. A minute, and it covers the whole project.
- 3
Explicit approval when each phase closes
Signed, not a "go ahead" on a call.
- 4
And change requests noted on receipt
Even if you decide not to charge: what matters is that they are on record.
Watch out
Professional liability runs for years after delivery. That means the project archive has to outlive changes of system, staff and partners — and leaving it on the machine of whoever drew it is not an option.
What gets asked for when there is a problem
All four are answered by the same thing: the project file with dated deliveries. And all four are impossible to reconstruct afterwards from three people's inboxes.
Worth knowing
It applies equally to engineering firms, technical consultancies and design practices: the pattern is "we produce documentation that we deliver", and control is over delivery, not storage.
›What about drawings, which are many and large?
Deliver and record the set per phase; there is no need to version each file by hand.
›Does it work for collaborations with other practices?
Yes, and there it pays to agree beforehand who keeps the whole.
›How long must the project be kept?
Longer than the applicable liability period, with margin.
A real case
The situation
A practice discovers at the end of a project that it did three unbilled rounds of changes.
What you do
- Notes each change request on receipt, even when not charging
- Records each delivery with version and recipient
What you get
The next project closes with the real scope billed and no argument about what was approved.
The situation
The design lives on the machine of whoever signs it.
What you do
- Stores it off personal machines
What you get
One person leaving does not take the archive.
The situation
The input data supplied by others disappears.
What you do
- Stores what third parties provided with the project
What you get
The basis of the calculation still exists.
The situation
Several versions circulate and nobody knows which stands.
What you do
- Keeps versions with their dates
What you get
You can say what applied at each moment.
The situation
Something is changed on site and never reaches the practice.
What you do
- Records what was communicated and when
What you get
Each party's position is documented.
The situation
Questions arrive about a project from years ago.
What you do
- Keeps the complete file with its date
What you get
You answer from the archive.
This article answers
- architecture project version control
- engineering deliverables by phase
- technical project documentation
- long-tail professional liability records