Contract documentation

3. What

<<Why | Who>>

3.1 Product

The contract documentation product (i.e. the contract documents) comprises

• the rules of play for purchaser and supplier; and
• the description of the products and services to be provided.

Purchaser and supplier are generic terms, used in the ISO 9000 quality assurance standards for example. The purchaser, in construction, is known as the client or employer (rarely, the principal or the proprietor), and the supplier as the contractor or builder. The supplier is not a subcontractor – these folk are in contract to the builder, not to the employer.

Products to be provided include buildings, landscape, spares, and tools. Services to be provided include training, maintenance during the defects liability period (usually 6 or 12 months, starting when the building is handed over to the employe), and commissioning.

3.2 Suite of documents

The documents come in a suite (even for small building projects), so it is important to 'say it once and (therefore) in the right place'. This way there is minimal conflict, and requirements can be readily located.

Rules of play: Matters covered in the rules of play should not also be covered in the description of work, and vice versa – this only creates conflict and confusion.

The tender phase is when would-be suppliers evaluate the required work and submit their proposals for carrying it out, mostly in terms of time and cost. The employer or its agent (commonly the architect) cross-compares the tenders and selects one, if all goes well. Two-stage tendering is also possible.

Instructions to tenders: These describe cut-off date, standard format, address to which tenders should be delivered, evaluation criteria etc.

Tendering is over when the conditions of contract come into play – the two are mutually exclusive. In other words, though the tender bundle will include the contract documents for information (as the basis for the tenders), the contract documents do not deal with tendering at all.

Description of work: The work – the built product and its component products, and associated services – will be described in various complementary ways. Some things are best described using drawings, some using text, some numerically, and some using other media such as photographs and models. Something described using drawings should not also be described using text, and so on. Again, this would only create conflict and confusion.

3.3 Content

The rules of play:

• anticipate events ranging from the certain to the unlikely; and
• state how they will managed, e.g. communications, timing, costs.

The conditions of contract deal with essentials for even the best-run contract, such as identity of the parties to the contract, critical dates, agreed costs, payment regime, insurance of the works, modes of communication, intellectual property, compliance with legislation, and procedures at completion. They also deal with matters which may crop up if things go wrong, such as bankruptcy, non-performance, and dispute resolution.

The description of work describes certain

• entities, e.g. systems, and component, fabricated and built products; and their
• attributes, e.g. scope, layout, assembly, and quality.

It is not good practice to draw the same thing more than once, or specify the same thing more than once. A good example of the latter is trenching, which could be in a trenching specification section, or in each of several trenched services sections. Multiple specification could bring about conflict, generates unnecessary bulk, takes longer to write, and could also mean that the item is priced more than once.

Entities: Component products are off-the-shelf, manufactured or processed. Fabricated products are purpose-made for the project, but not in situ. They are often made off site. Built products are purpose-made in situ. The building as a whole is the ultimate built product.

Attributes: Scope, layout and assembly are usually described using drawings. Quality is usually described using a specification. Other attributes will be described in other ways, e.g. quantity and cost, using bills of quantity.

3.4 Form

Proactive documentation collectively forms the basis for the contract, and is signed by both parties (purchaser and supplier) on acceptance of the tender. It typically comprises drawings, specifications, and contracts.

Reactive documentation only amends the contract if implemented by an instruction, e.g. approving a proposal or a shop drawing. It typically comprises:

• Instructions, variations: These amend or supplement the contract. On large projects hundreds, even thousands, may be issued. They originate from the employer side. Not all instructions vary the contract.
• Contractor proposals: Design proposals, responding to performance requirements for bespoke items in the contract documents.
• Shop drawings: Prepared by fabricators to show how they propose putting together an item described in the contract documents only fairly superficially, e.g. in terms of finished form. Another response to the contract documents, where they should be stipulated.
• Manuals: Operation and maintenance manuals are actually one of the products required, one of the deliverables, but they are reactive in that they are about the work as built, not as originally contracted.

3.5 Hybrids

The different types of information can be combined in different ways to create different documents. This can make it difficult to ‘say it once and in the right place’. A clean split between quantities, drawings, specification and contract is desirable, but rare.

Annotated drawings: Conflict between drawings and specification is very common. Inappropriate annotation is the main reason for this.

Written description: This material (the specification) can be scattered across 4 or 5 documents in a single project. Making matters worse, specifiers not infrequently include ‘rules of play’ in their material, unaware that they are covered in the contract itself.

Contract: Most contracts have something to say about ‘materials and workmanship’. One reason for this is that specifications have been poor in the past, and the employers cover themselves with catch-all requirements in the contract. However, these may conflict with the more precise requirements of the specification itself, undermining it (Gelder, 2003).

3.6 Process

The contract documentation process can be seen as one of a nest of projects. Documentation is a project because it occurs in stages (inception, design, execution, finish) and the documentation team is multi-disciplinary and transitory. The documentation project nests into the building procurement project, which nests into the facility realisation project. Documentation in turn breaks down to a series of subprojects, e.g. specification.

So documentation can, and should, be project managed.

3.7 Procurement

There are two broad classes of procurement: head contracting and package contracting.

In head contracting a project is let to just one contractor, who subcontracts. This entity may be called the prime contractor, the builder, or the general contractor. The contract documents comprise just one set of stuff. Any disassembly of this material, e.g. for subcontracting, is the contractor’s responsibility.

The subcontract boundaries are the contractor’s affair. The structure of the drawings, the specification and the bills has no bearing on the way the work will be subcontracted. However, work sections in the specification broadly reflect trade divisions. But it is a mistake to think that they dictate or should exactly reflect the way the project is to be subcontracted.

Because this is the builder’s affair, and because the builder does not exist at the time the specification is prepared, the subcontract boundaries cannot be known to the specifier.

In package contracting, a project is let to a series of contractors, who subcontract. The main difference between this method of procurement and head contracting is that there are boundaries around packages to be considered. These involve both permanent works and temporary works interfacing. These are the concern of the documentation team, and will affect drawings, specification and bills. The package boundaries must be defined in the contract documents.

But as for head contracting, the subcontract boundaries are the contractors’ affair.

A hybrid method of procurement, nominated subcontracting, also requires boundaries to be resolved, this time between the subcontractor and its head contractor. Again, this falls to the documentation team.

Other forms of procurement: Head and package contracting is just about the number of contractors. Other variables include who designs, who finances, who manages, and who maintains the contract (whole building or package) – the employer and its team, the contractor and its team, or both sharing the responsibility in some way. From these considerations we get design-build contracting, PFI (private finance initiative) projects, construction management, and BOOT (build-own-operate-transfer) schemes, for example. Many permutations and combinations are possible.

3.8 Key points

Contract documentation comprises rules of play for both parties, and the description of products and services to be provided.

The documentation is organized as a suite of complementary documents.

Rules of play anticipate events and state how they will be managed.

The description covers relevant entities and their attributes.

Entities may include manufactured, fabricated and built products, as well as higher level things such as elements and facilities.

Different attributes are described using diferent types of document, e.g. assembly is shown on the drawings, quality is described in the specification.

Reactive documentation comes in several forms.

Different types of information are usually mixed in hybrid documents, such as annotated drawings, though this is not generally desirable.

The process of documentation is a project in a nest of projects.

For head contracting, disassembly of the contract documents is the responsibility of the contractor.

For package contracting, the documentation team must decide where the boundaries between packages lie. Each contractor remains responsible for disassembly of its own contract documents.

<<Why | Who>>

BackToTop