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.
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.
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.
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:
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.
Limitation of liability clauses are often the subject of extensive negotiations between business to business parties of an IT contract. It is difficult to escape the conflict between the competing priorities of customer and supplier - the customer aims to secure the maximum protection available against future losses but the supplier wants a level of liability to match the perceived value of the project to it. How wide can the supplier go to limit its liability and what does a customer need to do to ensure fairness while maintaining some certainty as to the losses potentially recoverable?
1 / 4 观点
The Internet of Things has been touted for some years now as the brave new world of technological development that will transform business and homes beyond recognition. Some of that early promise is now being fulfilled, but while the benefits are clear, IoT devices also bring a number of risks. Some of these will be new manifestations of old legal problems, others may raise interesting new legal issues which will ultimately only be clarified by the courts. In the space available, we can only give a high level view of some of the issues which we see being the subject of disputes over the coming years.
2 / 4 观点
In 2016, ransomware incidents were reported to have increased by over 300% – with the number of attacks still on the rise. Ransomware is a form of malware that blocks a user's access to its system or files through encryption until a ransom is paid, although payment doesn't always guarantee returned access.
4 / 4 观点