The contract is agreed, the documents are not
The tender is accepted and the client wants to sign. Your practice is responsible for preparing the contract documents. That means the contract form and its particulars, the employer's requirements or drawings and specification, the priced document, the tender addenda, the agreed answers to tender queries, and anything changed in post-tender negotiation.
Somebody has to find the final version of each. The drawing register says revision D; the tender pack had revision C; an addendum issued revision D for three drawings but not the others. The post-tender clarifications are in an email thread with the contractor. It takes days, and at the end nobody is completely sure the set is right.
Why compiling the set is hard
- Versions change during tender through addenda and query answers, and the changes are spread across emails and bulletins.
- Post-tender negotiations agree changes in emails and meeting notes.
- Drawing registers and the actual files do not always match.
- Nobody maintains a running list of what the contract set will be during tender.
- The compilation is done at the end, under pressure to sign.
What getting it wrong costs
A contract signed on the wrong version of a document creates the exact dispute the contract is meant to prevent. Delays to signature push start dates. The surveyor compiling it carries a lot of stress. And years later, anyone needing to know what was agreed may find a set nobody fully trusts.
| Document type | How its version changes | What the compiler tracks |
|---|---|---|
| Drawings | Revisions and addenda | Current revision per drawing, with the issue that changed it |
| Specification | Addenda | Clauses changed and the issue reference |
| Tender query answers | Bulletins | Answers that form part of the contract |
| Contractor's offer | Clarifications and post-tender changes | Final accepted terms with source |
| Contract particulars | Negotiation | Agreed entries with source |
The contract document compiler
- At tender issue, the compiler records every document and its revision from your tender pack and register.
- Each addendum and tender bulletin is logged against the documents it changes, so the current version of each is always known.
- Post-tender clarifications and agreed changes are logged with their source, whether an email, meeting note or letter.
- At award, the compiler lists the proposed contract set: every document at its final version, with the changes that led there.
- Mismatches are flagged, such as a drawing referenced at a revision that does not exist in the file store.
- The QS reviews the list, resolves the flags and approves.
- The compiler assembles the set into a structured folder or a bound PDF with an index, ready for the parties and their advisers to check before signing.
What forms part of the contract is a decision for the parties and their advisers. The compiler assembles the evidence for that decision. It does not make it.
Award without the scramble
When the tender is accepted, the proposed contract set is already listed. The QS reviews the flags rather than hunting for files. Signature is not held up by admin. And the archive holds a clear, indexed set with a record of how each document reached its final version.
Post-contract, the same record helps the surveyor valuing variations, because it is clear which drawing revision the contractor priced and which came later.
Does your practice scramble at award?
- Contract documents are compiled only after award.
- Finding final versions of drawings means checking addenda by hand.
- Post-tender changes are spread across email threads.
- Nobody is fully sure the signed set is right.
- Finding what was agreed years later is hard.