I attended a presentation the other day where the speaker was exploring the very topical issue of the likely fortunes for the Australian economy following the collapse of the mining boom.
Being more optimistic than most, he was describing in reassuring tones some of the natural competitive advantages that Australia possesses, when compared to our competitors in the region. I was mildly surprised to hear our rule of law included in that list.
It’s surprising because as a lawyer working on technology contracts, I have never really had cause to doubt whether the commitments I capture in a contract are enforceable (they are).
Quite rightly, however, the speaker made the point that for many countries around the world, including some of our regional trading partners, this is not necessarily a given.
I’m conscious that many project managers responsible for managing an IT vendor prefer to leave the contract in the bottom drawer. Even as a lawyer, I acknowledge there is a time and place for this style of relationship management (although I don’t think it should be the normal mode of operating).
But for those who choose to manage to a contract, or who pull the contract out in moments of frustration or desperation, I have a prediction.
When a disagreement arises in the delivery of IT services, the dispute will almost always relate to the part of the contract referred to as the “back end” – the contract schedules.
In the technology context, this is the part of the contract that describes the goods or services being provided, the service level mechanics, the pricing, and the governance.
As you can see, while they may be at the back of the contract, they are not just the minor details. They describe the essence of what is being provided, when, and for how much.
The contract schedules are not the natural hunting ground for most lawyers. Rather, the attention of a lawyer is almost invariably fixed on the “front end” of the agreement.
This is the part of the contract that contains the agreed terms and conditions (you know, the “legalese”).
While provisions dealing with liability, indemnities and insurance are fundamental, and need to reflect an appropriate allocation of risk, a failure by either you or your lawyers to focus on the details in the contract schedules can be a wasted opportunity and end up costing you serious money.
Here’s an example how this may occur. While a service description ought to describe what the vendor is responsible for providing, vendors often include detailed assumptions upon which those obligations are dependent.
These often completely excuse the vendor from the obligation to perform, or require the customer to pay the vendor additional fees. Often, there is very little governance around such assumptions.
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.
Tim Gole is a partner at Gilbert + Tobin
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.