If you are having trouble reading this email message please Click Here
M&E services to the rail industry - We Know How
Keeping in Touch - August 2011
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) firstname.lastname@example.org (expressing interest in coming to one of our events)
Pitfalls of writing good specifications
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.
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?
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
113-117 Farringdon Road, London EC1R 3BX. | Tel: 020 7060 2332 | email: London@fdal.co.uk