For the majority of IT projects, the contract and, just as important in terms of flushing out crucial information, the negotiating process leading up to signature, can play a big role in influencing the direction of the project, as well as helping to resolve disputes efficiently in the event the project veers off course.
Planning
The importance of properly planning an IT project should never be underestimated, but many businesses fail to give proper consideration to the need to plan the contract negotiation process. It is crucial to plan ahead and allow a realistic amount of time both to draft and then negotiate a contract for an IT project. The bigger and more complex the project, the more time will be needed. Lawyers are used to working under pressure but, whether they are external lawyers or the in-house team, they cannot achieve the impossible. If time becomes short due to unrealistic deadlines, the contract will suffer. Things may be missed out that the parties or their lawyers did not think about in the rush. There may also be a conscious sacrificing of detail in the bid to get a document over the line which will give you a contract but, most likely, one which is too high-level and generic to be of much use in keeping the project on track.
The most practical advice, therefore, is to make sure your lawyers are given as much notice of a key IT project as possible and their views sought as to what is a suitable timeframe for the contract negotiation process.
Whose paper?
So many contract negotiations start with a 'courtship ritual' over whether the draft contract should be based on the customer's paper or the supplier's (i.e. who produces the first draft). This ritual can even turn into a minor squabble, which is not exactly constructive. Clearly, both sides will want to put their best foot forward, but the important thing is to end up with a contract that describes the project in the clearest way. As a customer, there is no point in ending up with a contract that is on your standard form and includes all your 'kitchen sink' clauses if that contract is not right for the project in question. This is a particular danger for larger customers with an in-house legal department that maintains a collection of standard-form precedent procurement agreements that the business is mandated to use. Naturally, these precedents are generic and usually designed to cover as much as possible. That does not mean they will cover your particular IT project well. For instance, a 'master agreement' which is designed to cover any kind of goods and services under the sun, from the supply of tables and chairs to window-cleaning services, is not going to be much use for papering a SaaS-based system implementation project. But customers push those precedents all the time. They often do so due to an irrational attachment to their own language and the inclusion of clauses they will probably never need, but that will not get them a contract that helps to keep the project on course.
One common pitfall is in relation to agile development projects. Most precedent agreements in circulation still seem to be based on a traditional 'waterfall' approach to IT development. An agile development methodology requires a very different approach, and it is not a matter of just changing one or two clauses.
There can be little doubt that for a customer, choosing to contract on a supplier's terms which are designed to cover the type of IT project in question, (provided the supplier has something suitable) will produce a better outcome than using a generic 'home grown' one.
Having said that, a common problem (for customers) with suppliers' standard-form agreements, is that they tend to be overly concise and devote little attention to describing the services and deliverables they are actually supposed to be covering. Many suppliers believe that customers are more likely to sign short documents without significantly challenging them. While that strategy certainly does work on some, the majority of customers are more sophisticated and will expect to see more detail in the contract. Suppliers should, therefore, not shy away from using a longer document that properly describes what they are going to do and provide as this is likely to prove more palatable to the customer and speed up the negotiation process.
Another issue with suppliers' standard-form agreements can be that they are frequently disjointed. This presents a real risk for the customer. For a typical IT project that involves software licensing, IT development and implementation, ongoing support and maintenance and, possibly, ongoing hosting too, some suppliers can proffer up to four different sets of terms as the basis of the contract. If the terms do not dovetail (and more often than not they don't), the parties risk setting up a contract which is not going to help them at all if things start to go wrong. Inconsistency in a contract should be strenuously avoided, because it is likely to prolong any dispute and make the outcome uncertain. Even if the terms are not inconsistent, it may be very hard to tell, in this situation, whether issues fall under one set of terms or another. This should be a concern, especially for the customer.
It is not uncommon to see a party's standard terms presented but overlaid by an addendum that varies certain clauses, because that party refuses to amend the terms in the base document itself. There are few tactics likely to irritate the other party more (and at a time when you are trying to engender good will). In addition, even if the other party accepts it, both parties will end up with a contract that is much harder to read. If a contract is hard to read, it is more likely to end up in a drawer following signature, rather than be used to support the project, and will only be brought out in the event of a dispute, at which point, it is likely to be of little use.
Services Description
Getting the services description right is, without a doubt, the single most important contractual element in ensuring a successful IT project. The best and most robust legal clauses in the world will not help you if the services description is too high-level, vague or ambiguous. One of the main reasons IT projects fail is due to a mis-alignment in the parties' expectations about who is doing what, when. A good service description takes time to write, but it is time well-spent and should be factored into the planning stage.
All too often, the technical team (whether on the supplier or the customer side) will not be particularly adept when it comes to drafting service descriptions because, understandably, technical matters, rather than words, are their stock in trade. By contrast, lawyers are good with words but are not always close enough to the technical detail to be able simply to draft something. If lawyers have to become involved in drafting services descriptions (which, is not generally a cost-effective use of legal resource), a lot of time needs to be factored in to the exercise, which tends to involve the legal team sitting down side-by-side with somebody from the technical or operational team to work through the project.
Pitfalls to avoid in services descriptions include:
- Lack of chronology - the services description should tell a story – that story being, quite simply, what the supplier is going to do, when they are going to do it and what the customer may also need to do along the way. The simplest, clearest and most logical way to tell a story is chronologically. The services description should, therefore, be couched in terms of "The Supplier will do X, then the Customer will do Y, and then the parties will agree Z" and so forth. A frequently used alternative approach is to list all the supplier's responsibilities and, separately, all the customer's responsibilities. Whilst this can be made to work, it is more difficult to arrive at a clear contract since, more often than not, the supplier's responsibilities have to link up with those of the customer and it should be clear from the face of the document where (and when) those links are.
- Use of capitalised terms which are not defined - non-lawyers often seem to assume that, by using a capitalised term, it somehow acquires a certain meaning (presumably, being whatever meaning that person had in his/her head when including it). The truth is that such a term could mean different things to different people – leaving room for later dispute. In short, every capitalised term should have a definition or else be rendered lower case. Even when using lower case terminology, make sure it is consistent. For example, if the contract refers variously to 'roll-out', 'implementation' and 'go-live', it can be unclear whether or not these mean the same activity or different ones.
- Use of the passive voice - services descriptions frequently talk about something happening without it being clear which party is responsible for making it happen. As a rule of thumb, it is better to use the active voice and begin most paragraphs with "The Supplier will…" or "The Customer will…".
- Disjointed approach to services -v- deliverables - the two are intimately bound up. Deliverables are the output of the services. Therefore, if there is going to be a separate list of deliverables, make sure that the services part of the services description speaks to when and how those deliverables come into being.
- List of assumptions - long lists of assumptions should be avoided. They beg the question: what happens if (for whatever reason) the assumption proves untrue? Does it mean the supplier is off-the-hook, does it mean the timetable can slip, or does it mean estimates go out of the window or the charges go up? It can be anyone's guess. More often than not, assumptions are not merely assuming something to be the case but actually a clear obligation. For example, if the assumption is "The Customer will make available a test environment", that should be an operative obligation on the customer and the customer should realise that that is something it has to ensure. It therefore belongs in the relevant (chronological) part of the services description, right before where it says the supplier will install the system in the test environment (for example). It does not belong in a detached section of the services schedule (frequently in the 'dumping ground' towards the back) among a long list of disparate assumptions.
'Legals' -v- 'commercials'
There are very few purely legal clauses in an agreement (with the exception of things in the interpretation section like the neuter including the masculine and feminine!). Even so-called boilerplate clauses, such as assignment or third party rights, can have commercial implications. Most certainly, the commercials are not confined to the clauses dealing with charges and invoicing. The project stakeholders on both sides have a vested interest in understanding and being on board with the vast majority of clauses in the contract and, therefore, need to be engaged throughout the negotiation process to ensure the contract they end up with is something they can work with and, if worst comes to worst, something which can be used to sort out any disputes easily, at low cost, and without recourse to legal proceedings.
This article first appeared exclusively in Commercial Disputes Resolution.
If you have any questions on this article please contact us.
