I have written before in this column about the importance of clarity in technology contracts.

I was reminded of this while sitting in the audience at the recent CIO Summit. Aaron Powell, Chief Digital Officer at NHS Blood and Transplant, gave a terrific presentation about how CIOs can best influence their boards through communication, education and triangulation.

His story of the need to use plain, jargon-free language to explain the role and importance of, for example, hypervisor technology to an eminent haematologist, put me in mind of similar experiences when faced with eminent judges and unnecessarily complex, jargon-filled technology contracts.

Technology contracts ought to be easy to use and to understand unaided. Too often, that's not the case.

It's one thing to have the front-end of a contract drafted in over-complicated legalistic English. But the problems of contractual interpretation and enforcement get compounded when the key technical schedules - which is very often where most misunderstandings and legal claims arise - are dense, impenetrable to a layman and full of inconsistencies and ambiguities.

You don't have to dumb down a technical specification to make it readable, but it's always worth the time and effort to work out how hard it would be to explain to a non-technical layman (think of your lawyer, for example!) what the spec actually means. Better to do this before signing than in a court or before an arbitral panel.

A good test is whether the person who writes the front-end legal terms can understand and explain clearly the technical schedules - and vice versa. This also reflects a core principle that a good contract must be discussed and documented so that it expresses ensure the joint understanding of the parties.

A group of lawyers at the Society for Computers and Law is trying to take forward this idea that technology contracts can be made better, more usable and less dispute-prone. Through use of the best new drafting techniques and processes to score contracts for readability, the aim is to target an output that all those involved in a transaction can read and understand without additional guidance or support.

But it's important that this process doesn't just stop with the legal stuff. Clarity is important all the way through a contract document. English law and the legal system exist to determine and enforce what the parties to a contract intended by the contract language at the time they wrote it. Claims that "I know it says that but that's not what we meant" hold no water.

Gone are the days parodied by Not the Nine O'clock News in the 1980s with judges unaware of the existence of digital watches. The legal system now is much better equipped to deal with technical disputes, whether in the courts or via technical mediators and arbitrators. But that's no reason to make the job of enforcing technical requirements harder than it needs to be.

SLAs or schedules setting out technical requirements and solutions or customer obligations ought to be clear and capable of straightforward interpretation. My fear - and maybe here I display my cynicism - is that too often the level of complexity reflects a deliberate desire to obfuscate on the part of some service providers. It ought to be one of the tasks of a CIO's team to shine a light into the darker corners of any technical part of an IT contract.