ºÃÉ«ÏÈÉúTV

Most people, with the exception of a few peculiar individuals, do not regard specifications as riveting reading. In fact, I have often commented to colleagues that we spend our lives writing documents that nobody reads – until problems arise after the contract has been signed. When this happens, the specification is read very closely, in the hope that it will provide a clear answer that supports the reader's case.

One leading industrialist said to me recently that his firm had only just realised how critical the specification was, and that in the past it had produced tenders without reference to the actual project requirements. Tell me about it. We writers seem to spend our lives pointing out to others precisely what specifications require of them. Having said that, the best test of a specification is its ability to resolve disputes during construction.

Standardising the specification has to be one way to get that kind of clarity. The snag is that different disciplines produce information in a mish-mash of standards and formats, some with preliminaries, some without … Solving this will be a major challenge over the next two years. In the mean time, the specification writer is best advised to prepare the document in as structured and user-friendly way as possible.

There are many reasons for wanting to specify something, and an equal number of ways of actually doing so. Although details differ, there are common principles that, if applied, assist greatly in the usefulness of a specification.

A properly structured document is the key to success, and the use of a published classification system such as Uniclass or Masterformat is the best starting point. If the rest of the team can be persuaded to adopt that format, benefits will result. But persuaded by whom? In my view, this is most likely to be the architectural specification writer, particularly if they are the design team leader. Personally, whenever I am in that position, (or, even better, when the engineers et al are actually subconsultants to the architect), I always insist that the project specification be a "single" document, with one common general section and consistent formatting, to include numbering, fonts, layout and so on. I am surprised that clients do not insist on this more often, as it does flush out inconsistencies and clashes between documents and so reduces the risk of claims.

Once a classification system has been chosen, the structure of the document should be addressed. At this stage, the specification writer has to consider the use and purpose of the document. This should be thought of as a set of steps that leads the reader through their responsibilities, and which becomes increasingly detailed.

Another pitfall is providing too much detail in the first few pages, as this often results in the rest of the document being ignored

The need for a preamble or general section at the beginning is absolute. Each project case has to be considered on its merits, and decisions taken with regard to the need for preliminaries, submittals, quality control, which may or may not be covered elsewhere.

In my opinion, preliminaries should usually be in a separate document, but other sections may also be covered by the project management or construction management documentation. This issue is further complicated by the mixing of preliminaries and specification clauses in some standard specification products. It is critical, however that the specification be a stand-alone document that relates to the final permanent works, and the specification writer should not allow it to be diluted. So, items such as procedures, testing and quality requirements, materials and workmanship must be included – to comply with the British Standard definition if nothing else.

Another pitfall is providing too much detailed information in the first few pages, as this often results in the rest of the document being ignored. The story line should start with general responsibility, and requirements, moving through general descriptions of the project and trades and finally to precise material, workmanship and testing requirements.

A list of contents can be useful but again, it should be progressively detailed, with early sections providing the user with an overview of the overall contents, and each identifiable section providing a more detailed index of clauses.