Although 86% of the audience at the 2017 CoMIT Conference did not think language was the biggest barrier to digital contracts, we cannot automate our current contracts. The problems include:
- Jargon: the legal language is one-sided and full of jargon so the obligations are not universally understood within our industry, never mind by those who would have to translate words into code. Jargon encourages mistrust and adversarial behaviour.
- Complexity: the contracts are too complex – JCT SBC 2016 is 50,000 words, and often comes with another 50,000 words of amendments; FIDIC 2017 is even longer (it weighs a kilo). Contracts have significant numbers of clauses conditional on each other (cross-referencing) which is harder to separate into discrete promises.
- Input-based: the language of contractual obligations is based on inputs that are subjective eg reasonable skill and care, good industry practice, reasonably fit for purpose, to the satisfaction of the contract administrator; not objectively measurable outputs or deliverables. A computer cannot translate subjective behaviours. It needs yes/no options (zeros and ones).
- Adversarial: the contracts act as sticks (or heavy bricks) to use as a weapon against the other party, not as a tool to help them collaborate on aligned aims (as Jennifer Macdonald described when discussing Project 13). We cannot automate remedies in the same way we can automate payments.
- Encourage Negotiation on Minutiae: these factors create an industry in negotiating contracts; but to automate we need to simplify so that we are not constantly battling the small print and are just negotiating project specific issues. #TinyLittleContracts would reduce the time wasted in current contract negotiation and minimise the risk of starting a project without the contract terms being agreed.
- Comprehensive not flexible: automation requires deep understanding, cultural change and communication to be effective. If our contracts attempt to cover every eventuality they stifle understanding, create barriers to behavioural change, force communication down strict procedural channels and prevent flexible approaches to events that occur.
What should we do?
Before we create digital contracts we can start to use visuals like timelines, colour coding, charts, tables and infographics to encourage the industry to read and start to understand their contracts. We need contracts which are transparent, live and collaborative (#tlc). This is an essential step to creating digital contracts.
PS Interestingly, although language is clearly a barrier to understanding new and emerging technologies, not many of the other speakers mentioned it. Nick Tune at Atkins talked about how contracts do not work well with BIM. There are issues relating both to collaboration and jargon – since the CoMIT conference, Dan Rossiter has introduced the #ConstructingPlainLanguage charter to sidestep some of the jargon issues I identified here and noted in the Winfield Rock report.
