Field notes: the contractor who kept pouring against superseded drawings
A mid-size civil contractor had two rework incidents in one quarter, both traced to old revisions on site. Here is how one register and a transmittal habit stopped it.
The fluxems team · Field notes
A site drawing register showing current revisions next to superseded ones
blog/field-notes-superseded-sheet-rework/cover.png
This is a composite story from the field, anonymised and simplified, but the pattern will be familiar. A mid-size civil contractor in Gauteng had two rework incidents in a single quarter. Both times, the crew built exactly what the drawing in their hands showed. Both times, that drawing had been superseded weeks earlier. The concrete was right. The revision was wrong.
The situation
The team was not careless. They had folders on a shared drive, a WhatsApp group for urgent updates, and a site office with a plan table. The problem was that each of these was a partial copy of the truth. The engineer emailed new revisions to the contracts manager. The contracts manager saved them to the drive when he got a moment. The site agent printed from whatever was on the drive that morning, or from a PDF someone had forwarded the week before. There were roughly four places a drawing could live, and no single answer to the question that matters most on site: is this the current one?
What kept going wrong
When we walked through the two incidents with them, the failure modes were not exotic. They were the ordinary ones, repeated until one of them landed on a pour day.
- Revisions arrived by email and sat in one inbox until someone filed them, sometimes days later.
- The shared drive had no notion of superseded. Old and new revisions sat side by side with similar filenames.
- Nobody could prove what the site office had actually received, so every dispute became memory against memory.
- Printed sets on the plan table went stale quietly. Nothing flagged them as out of date.
- When rework happened, the argument about who issued what took longer than the fix itself.
What changed
They moved the drawing set into a single document register in fluxems and made one rule non-negotiable: a drawing does not exist unless it is in the register. Each sheet keeps one reference and a controlled revision history, so when a new revision lands, the team marks it with Set as current and the old one is visibly superseded instead of quietly competing with it. The register answers the current-set question at a glance, and the versions and revisions history shows exactly how each sheet got there.
The second change was how drawings reached site. Instead of email and forwards, every issue to the site office went out as a transmittal with named recipients, and the document controller tracked acknowledgements until the site agent confirmed receipt. That receipt is the difference between "we sent it" and "they got it", and it is the piece the old process never had.
What it looks like now
In the two quarters since, there have been no rework incidents traced to a superseded drawing. That is the headline, but the quieter win is what happens when a dispute does come up. Instead of a week of email archaeology, someone opens the register history and the transmittal record, and the question settles itself in minutes: this revision was current on that date, it was issued to these people, and here is who acknowledged it. The argument does not survive contact with the record.
Start with the rule, not the tool
The register only works if it is the only source. Agree the rule first: nothing goes to site except through a transmittal from the register. The software makes the rule easy to keep, but the rule comes first.
The document register with the current revision marked and older revisions shown as superseded
blog/field-notes-superseded-sheet-rework/current-set-register.png
If your drawings live in more than one place, you are one busy week away from the same story. See how document control works in fluxems, or talk to us about moving your current set across.