If you are having trouble reading this email message please Click Here
Keeping in Touch - August 2011
Hello,
First, please find at the end of this email a brief technical note we have written on the subject of drafting specifications.
We have observed that writing things clearly and unambiguously can be difficult and give rise to
all kinds of problems later, the more so if it is a contract or a specification. We've set some
words out that may be helpful to you and your people. This is a particular area of expertise in
which we specialize and our team would be glad to support you further if you find that you have a
need for getting drafting perfect.
Secondly, we mentioned in our last communication that we were going to start a series of short informal seminars to
help keep our clients up to date and perhaps support professional CPD requirements. We can now
announce the first two.
On 29 September we will be holding an evening session
entitled "The background to the proposed 2013 amendment to the Building Regulations Part L"
which is aimed to support your knowledge of the
regulations, what the changes are intended to
achieve and how this might affect you. The
speaker will be Ant Wilson from Aecom and will be
held at our offices in the early evening when we are
sure you will find the time spent very worthwhile.
The second event will be on 30 November and the
subject is "Cable Management Systems for Rail Infrastructure"
hosted by Dave Burton and a speaker from Legrand.
More information will be sent out nearer the time.
For reasons of
space we do ask that you let us know you will be coming
to the event on 29 September; you are all welcome but please advise by
expressing your interest as soon as possible or using the link below.
Thank you for your attention
Dave Burton, Mike Horne and the FDAL Team
(t) 020 7060 2332
(e) London@fdal.co.uk (ordinary correspondence)
(e) cpd@fdal.co.uk (expressing interest in coming to one of our events)
Technical Note
Pitfalls of writing good specifications
Introduction
Anyone buying a product or service will need to provide a specification of what is required. This specification is often attached to the contract (or purchase order) in the form of a simple schedule so that the description of what is required is set out in one place; the specification thus becomes part of the contract terms..
It is our experience that the quality of contract specification is highly variable. Sometimes it includes too little information, and sometimes too much. Sometimes what is wanted is clear, sometimes it isn’t.
The main problem is that many people may know conceptually what they want, but when it comes to writing it down it becomes a challenge. It goes without saying (or should do) that not being clear what is wanted before anything is written down at all is a sure route for a problem later.
Actually, writing clearly and concisely is a skill, or an art, and something many people do not naturally find easy, especially if it is not done frequently. That is why we’re here to help.
Poor drafting is one of the main factors leading to arguments later, when the person building the product or supplying the service quite reasonably interprets what is actually written differently from what the specifier had intended to convey. This can have lots of unwanted consequences, ranging from getting an unusable product, or the wrong quality of service, or having to pay for lots of unexpected variations. In any event it is likely to sour contractual relationships which could have further repercussions later.
In most cases the problem is that the specification has been poorly drafted. Writing clearly and concisely can be challenging and not everyone can do it well. The worst examples can emanate from people who simply don’t understand there might be a problem and where only good fortune has failed to offer up catastrophe. Sometimes understanding suppliers will compensate for the inexperience of the client but ultimately the client will pay for this. However, poorly drafted specifications represent significant business cost and risk — and the worst ills can be avoided.
Hints
A specification should be clearly written in simple English and jargon should be avoided. If jargon (technical language familiar to those in specific industries) must be used, then it is helpful to provide a summary of the words and what they mean in the context of the specification in hand. Where possible, stick to explanations that are standard within that industry.
Many evils can be avoided by defining terms properly at the start of the exercise. You would be amazed how the same words can mean different things to different people.
A specification should confine itself to the outputs expected from the equipment or service that is needed. It may be necessary to insert constraints into the specification. For example, a piece of equipment may need to fit into a particular confined space, or operate within a specific temperature range, or be less than a certain weight and so on. A service may need to be performed by people with a particular kind of safety training, or differently on bank holidays. It is often convenient to place all the constraints together, for ease of reading. Only as a last resort should specific ‘inputs’ be set out, because this limits the contractor in what they can do and passes a lot of risk back to the client (if what is wanted doesn’t work the contractor will point out that you asked him to do it that way).
Requirements should be set out once, and once only. Many requirements reference external documents, like professional or national standards. If something you want done is already set out in such a standard then do not separately set it out elsewhere. This reduces the opportunity to specify an outcome in two different and perhaps conflicting ways and makes future editing much easier. Can this happen? Yes, all the time.
Following on from the above it is easier for all concerned if all the material requirements are set out in one place in a document. It is confusing and time confusing if some requirements are in one place but other requirements (maybe even related ones) are in another part of a document. Trying to work out what is needed in these circumstances becomes at best frustrating and at worst likely to lead to mistakes.
Where external documents are referred to it is vital to refer to the specific version that is intended. For example, did one mean the version current when the specification was written? Or at the date of the contract? Or some other version, such as the version current when the work is to be carried out (sometimes years later)? Using expressions such as ‘Version 5’, or the ‘version current at the date of this contract’, or the ‘version current when the work is carried out’ would avoid this all too common source of difficulty. These terms all mean quite different things to any contractor and will impact on price, as the latter example represents an unknown possibility of change.
Consider also the consequences of any referenced documents ceasing to exist altogether and what conditions an uninformed court might choose to insert at some inconvenient time in the future. Consider the possibility that words in everyday use may be construed differently (and perhaps unexpectedly) by a court, which is the ultimate source of redress. Words like ‘day’, ‘midnight’, ‘reasonable’, ‘timely’, ‘exclusive’ and so on (there are far too many examples to quote here) all have well understood legal interpretations which might not be what you thought they were going to be.
Where you refer to external documents then (unless you specify otherwise) they, too, will become part of the agreement. If you feel the need to use your own definitions, they should on no account differ from definitions of the same words used in any document which you reference—that would be a recipe for ambiguity. You should not be tempted to exclude parts of external agreements simply because they are not relevant, because that might create other difficulties, depending on the complexity of whatever is attached. If you do need to exclude something, be specific about it. For example if you reference an ISO document setting out symbols to be used in any drawings, it is perfectly in order to say that (for example) ‘…symbols 1145 and 1146 in ISO [whatever it is] shall not be used and references to those symbols shall be construed as references to symbols 1145A and 1146A, respectively, in this specification. On the other hand these numbers should not simply be excluded because they are not used: all that does is create work and introduces new risk.
Specifications should be written starting from the most general requirements and working down to the particular. Drafting should be done in a way where it is clear that the particular is a subset of the general. If drafting is done in a way where material is written down simply in the order thought up, then it may not be clear whether requirements support each other or conflict with each other. Sometimes drafting is so muddled that contractors or bidders have to redraft it into more lucid form and ask the client if that is what they meant to say (others may take advantage of client shortcomings, however). It is helpful to keep parts of the specification relating to the same thing together if possible, or everyone might get into a muddle. Structure is vital.
Be clear about whether headings are significant or not to be taken into account as part of the specification and provided for information only. This may be set out in the standard terms and conditions (but do check if this covers the specification as well).
Be clear about what performance criteria will be adopted, or other means of indicating that you believe the contract to be satisfied. If you do not do so the law may come to a conclusion that is inconvenient for you.
When you think you have completed your drafting, get someone else to check it for sense. Bear in mind that spelling might be important but beware spell checkers that may not be familiar with technical language and replace a merely misspelt word with an entirely different (and wrong) word altogether. When amending drafting, look out for the common error of accidentally including or omitting the word ‘no’ or ‘not’, thereby entirely reversing the meaning of what is wanted (this happens surprisingly frequently). Another problem is leaving blanks in the first draft for later insertion of detail. It is surprising how often these blanks and question marks make their way into the final version sent out to tender. Try using violently different colours to indicate material that needs attention before anything gets distributed (we have lots of stories here).
It is tempting to cut and paste material to speed up drafting. Do make sure that the result looks professional and that you make all the changes that are necessary. We have received specifications from bodies (some of which you would expect to be masters of detail) that look as though they are the result of some hideous experiment with the formatting system that went wrong. How would one have confidence in such a document, and what do you think it did to their reputation?
Conclusion
The foregoing are merely examples of things which we have observed can be fixed easily. We have experienced specification writers on our team who have also had experience of managing contracts as well as responsibility for drafting them—so we do know how things can turn out in practice.
We would be delighted to help speed up your drafting and reduce business risk by offering your our hard-earned experience.
Click HERE to download printable version
We value your privacy and we're not going to sell or pass your information to anyone. If you really want to read the details of the privacy policy, you can read them here. To unsubscribe from our customer emails click here. To see web version click here.
113-117 Farringdon Road, London EC1R 3BX. | Tel: 020 7060 2332 | email: London@fdal.co.uk