A contract is not just a set of legal terms. Contracts include:
- processes such as change management
- deliverables and KPIs
- works information
- programming
- payment schedules
- policies and codes of conduct
A completed contract is a mix of commercial, operational, legal and technical items. The difficulty for most users is finding the elements of the contract that are relevant to them.
The accepted definition of plain language includes that users can find what they need, not just understand what they find.
Sample structures
Companies are increasingly finding that traditional contract structures do not suit their needs. Ecovadis changed their contracts from columns of small print into:
- the business part – an order form (similar to key data sheets)
- the legal part – your terms of business (you could even have one set of fair trust-based terms irrespective of whether you are buying or selling)
- the technical part – schedules (covering what’s really important to the staff who are managing/operating this project or transaction).
This demarcation of content is highly practical.
- The order form sets out in one place all the commercial elements of the transaction – you can pin a hard copy to your noticeboard or fridge, or see the details on your phone in one screen!
- The terms of business can be simplified; you could use core terms plus special terms or deviations only to meet regulatory requirements, your sector or local laws – this allows you to use a modular approach to creating terms of business relevant to this transaction (not terms plus amendments)
- the schedules allow your teams, departments or staff to find all the relevant parts of the contract that apply to them easily. So they’ll be less likely to ‘do what they’ve always done’.
This is similar to Verity White’s ‘reverse contract sandwich‘ or the use of key data that can be seen in my sample appointments.
Your contract could become as simple as a series of promises to meet the technical schedules covering time, cost, quality, deliverables, codes of practice and other aspects. This allows the schedules to adapt for each project, rather than relying on T&C which include detailed processes that might not be relevant or suit your needs.
If you want to get sophisticated, consider adopting elements from World Commerce and Contracting’s Pattern Library such as timelines, chronological order, swimlanes.
What should you do?
Consider how much of your contracts really change with each transaction or jurisdiction.
Aim to keep the commercial, legal, technical and operational information separate – this not only makes it easy to find what’s relevant but also prevents inconsistencies and ambiguities.
Collate terms based on who will use them not legal subjects – and adopt headings which are descriptive for users.
