Drawing revision management — version history is not revision control
The most expensive failure in a small practice is a revision that did not reach site. It is almost never anybody's fault, which is exactly why process cannot fix it and a system has to.
Ask any practice over five years old for its most expensive mistake and a version of the same story comes back: a revision was issued, something was built from the previous one, and putting it right cost more than a year of software.
What makes the story worth examining is that nobody in it was careless. The drawing was revised properly. It was sent. Somebody built from what they had. Every individual step was reasonable.
Why version history is not enough
Cloud storage gives you version history: the same file at different points in time. That is useful and it is not revision control.
A revision, properly understood, carries five things a file version does not:
- 1An identity — revision C, not 'the one from Tuesday'.
- 2A reason. What changed and why, in a sentence somebody can read a year later.
- 3An issue date, distinct from the date the file was saved. Work is finished before it is issued, and the gap matters.
- 4A recipient list. Who was sent it, which is the field that decides disputes.
- 5A supersede relationship. Revision C explicitly replaces B, so 'is this current' has an answer.
GF_PLAN_FINAL_REV_C_USE-THIS.dwg encodes exactly one of those five, badly, in a filename that a second person will not follow.
The three failures this causes
Building from a superseded drawing
The expensive one. Prevention is not more diligence — it is a single place where 'current' is unambiguous, and a transmittal record that shows who has it.
The dispute you cannot evidence
A contractor says they never received revision C. If your transmittal was a WhatsApp message or a phone call, you are arguing from memory against someone arguing from memory, and the commercial outcome follows whoever is more confident rather than whoever is right.
Internal drift
Two people working from different revisions in the same office for a fortnight. Quieter, more common, and it produces coordination errors that surface much later.
What good looks like
- One current revision per drawing, unambiguous to everyone including the client.
- A transmittal log recording drawing, revision, recipient and date — generated as a by-product of issuing, not as a separate discipline.
- Superseded revisions retained and clearly marked, never deleted.
- Client approvals attached to a specific revision, not to a project or a date.
- Access from site, because that is where the wrong drawing gets built from.
In Ofivio a drawing is a set with revisions, and issuing one writes the transmittal automatically.
See drawing managementRelated reading
What a client approval portal actually needs to do
Approvals that live in a WhatsApp thread are approvals you cannot prove. Here is what a portal has to do to be worth having, and what to check before buying one.
Can you run an architecture practice on a generic project tool?
You can run a practice on Trello. Plenty do, successfully, for years. This is about the specific and fairly predictable point at which it stops working — and how to tell whether you have reached it.