Most contracts lack even the basic concept that the vendor must tell the customer when it is being delayed by such assumptions not being performed.
The inclusion of assumptions is not, in itself, a problem. It is fair and reasonable that a vendor, particularly when working to a fixed fee, sets out the constraints upon which that fee is provided.
Recently, however, I reviewed a large managed infrastructure contract where the assumptions provided by the vendor were literally almost twice the length of the description of the services being provided.
When I asked the client whether they'd review them, the answer was no. As we worked through them, my client and I jointly came to the conclusion that some of the assumptions negated the very obligations that the vendor was being engaged to provide. A very much shortened list was included in the final contract. Buyer beware, indeed.
At a more complex level, examples abound of the risks that you and your advisers need to assess when contracting for IT projects or services.
For example, using ITIL to describe IT services has become commonplace. However ITIL provides no assistance in describing scope boundaries or handover points. Particularly in the modern era of "best sourcing", where it is likely that multiple vendors will be responsible for managing different parts of an IT environment, accurately defining these scope boundaries and handover points is important.
The back end of the agreement is also the mechanism by which you can arm yourself with tools to help create a flexible and transparent contract, so as to manage the agreement through its life and the inevitable technology and business changes.
For instance, creating separable service bundles that avoid cross-subsidisation will assist with benchmarking and multi-sourcing. Including flexible service level mechanisms that allow you to adjust service level weightings and introduce new service levels during the term will help future-proof the agreement.
And while you and your advisers should focus on these strategic goals, sometimes even a failure to get the simple things right can have significant consequences. Accuracy in definitions, and clarity and consistency in language, can help avoid unnecessary disputes.
I was recently involved in a dispute in an IT contract. The issue depended on the placement of a comma and a mere five words of unclear text. The dispute was worth several million dollars.
If the rule of law is one of Australia's natural assets, then it pays to leverage that in your dealings with IT vendors. Ensure the contract schedules don't contain inappropriate limitations and exclusions of responsibility.
Use them as a mechanism to build for yourself a relevant, flexible, and transparent method of delivering your IT project or service, which reflects your business and technology priorities.
I can almost guarantee, if something goes wrong with your IT contract, you'll probably be staring at the contract schedules rather than the front end legalese.
Sign up for CIO Asia eNewsletters.