It was great to meet a number of CIOs at the recent CIO Plus event on Vendor Management. The discussion among those in the room was really interesting as I tried to answer the question: What role does the contract play in vendor management?
And what did the room conclude? Well, people shared a pretty wide range of experience with a degree of consensus around the contract being too important merely to sign and put in a drawer never to be seen again – but also that it's less important than communication, alignment and diplomatic early handling of issues.
But, ultimately, if all else fails and you do end up in a dispute with a vendor, then that's where the contract comes into its own.
One of my concerns is the poor state of many contracts within the ICT sector. Of course, where contracts are done on vendor's standard terms and conditions, then there's not much that a customer can do. But even contracts that are specifically drafted often tend to be of less than optimal quality – and it's sod's law that any sub-par aspects of a contract only get discovered when an issue arises and the contract doesn't really provide the answer.
Many ICT contracts often consist of two elements sandwiched together: a "front-end" of legal terms and conditions drafted by the lawyers (which many of the technology experts may not necessarily have read); and a "back-end" of technical and financial schedules (which, reciprocally, many of the lawyers won't read). It's pretty common to find that these two elements don't fit together particularly well.
I've seen lots of instances of this over the years, and if I had one recommendation it would be to mandate that whoever writes the front-end legal terms needs to be required to sit down and read the back-end schedules – and vice versa.
So how should contracts be written? I still think there's no substitute for a plain English approach. Clauses full of hereintofore and howsoever really ought to have no place in modern commercial contracting. Similarly, many commercial or technical drafters can produce a terrific technical document, but seem to want to turn themselves into amateur lawyers when faced with a request to produce something that can be contractualised. There are lots of simple tips to producing a good contract document. A few are:
- Only include things that are relevant to the contract; don't include extraneous information or padding. Marketing people: this means you.
- The dominant focus should be what the parties have to do. Make technical and service schedules as obligation-driven as possible.
- Use definite language – "shall" or "will" – and not conditional language such as "may" or "should".
- Try not to leave things to be agreed between the parties – i.e. try to specify all of the requirements up-front. If you have to agree to post-contract "calibration" of service levels, maybe either you or the vendor aren't ready to contract just yet.
- Use clear and precise language. The technical schedules should be capable of being understood by other people in the business and, ideally, by someone without prior background knowledge of the deal.