10 commandments for writing an IT contract

Alistair Maughan, partner at technology law firm Shaw Pittman, preaches 10 lessons you should obey when drawing up a contract for...

IT projects have a bad reputation for going wrong. In the public sector there were problems at the Passport Agency, with the benefits payment card project at the Department of Social Security, and with the Immigration and Nationality Directorate IT systems. The private sector is often not much better, except perhaps in terms of its ability to keep contract disputes private and deal with them out of the public eye. As IT projects get bigger and contracts grow longer, the risks of something going wrong - and the consequences - also increase. While the underlying causes of project failures are many and varied, the IT contract itself often gets the blame. This is because the contract represents tangible evidence of the parties' agreement and, in the end all arguments somehow lead back to the contract. So are there ways to avoid or at least minimise the risk of problems arising with an IT contract? Here are 10 guiding principles which, if they are followed, should lead to more successful IT contracting. Remember that an IT contract is like a marriage: the customer and supplier need to work together for the whole of the contract term and, if all goes well, will hopefully develop a relationship beyond that. Make certain that everyone involved (including the lawyers) knows this and knows that the aim is to produce a contract that both sides can live with. Too often, negotiations end up in a series of "point-scoring" arguments, which achieve nothing except to start off the contract relationship on a bad footing. The contract should reflect the objectives of both parties and should be driven by the business needs, not the other way around. The customer should understand that the supplier needs to make a realistic profit and to be incentivised to do so. Squeezing the supplier dry is a way of disincentivising the supplier to invest further resources in providing a good service or will simply force the supplier into raising change controls for every single minor change. Likewise, suppliers need to recognise that customers are focused on ensuring that the service continues to reflect its business needs and that constant references back to change control serve only to aggravate the customer and potentially destroy the long-term relationship. Building flexibility into an IT contract is probably the hardest and most overlooked aspect of the whole process. Too often companies contract solely for present requirements without paying attention to the fact that the contract will rapidly become out-of-date unless it is flexible and can change to meet developing needs. Parties need to think about the way services or software will change, and build in processes to anticipate that change. This may mean building in benchmarking, indexation or technology-refresh plans. It could also require mechanisms to ensure the price varies according to volume in known, predictable ways. Alternatively, companies will need to create mechanisms to ensure and enable expansion or contraction of their businesses by merger or disposition without leading to loss of service. The aim must be to make change predictable and to ensure that the contract is as elastic as possible. This takes innovative thinking and consideration of all the relevant circumstances. Make sure that the contract provides certainty for both sides. This means certainty as to scope, performance levels and price. Ensuring that certainty exists is vital if both sides are to get what they want out of the contract and so that they can collectively reduce the potential for disputes in the future. Make certain that the contract fits together. A common failing is that all the parties see the contract as a "front end" (ie, the legal terms and conditions) and a "back end" (that is: all the technical schedules). The lawyers draft the front end, the technical people draft the back end, and then the two halves are fitted together at contract signature. The problem is that it is unlikely that the two halves will have been prepared in conjunction with each other and there is massive scope for ambiguities, misunderstandings or omissions. The contract should be seen as a whole, being driven by the commercial objectives of both sides rather than by the legal issues. So, issues such as service and price need to be prepared in conjunction with each other; and likewise, service, service levels and other remedies need to be drafted as a whole rather than as two separate parts. Even lawyers should recognise that, even though legal issues are important, the parties' commercial drivers are paramount. So negotiations should focus on key issues such as around service, price and scope before progressing on to the niceties of warranties, data protection and indemnities. If they know what they are doing, lawyers certainly have a role to play in structuring and documenting the commercial discussions. They need to be involved early enough to do so but managed effectively so that legal issues are not given undue priority. Deal with exit up-front. Earlier this year, analyst Gartner estimated that organisations without an exit plan would experience costs of switching supplier that are 100% higher than those with an agreed exit plan. Try to anticipate what will happen at the end of the contract and agree in advance the exit plan. The most controversial thing about exit is that it should be non-controversial. Exit is bound to happen at some time and it needs to happen in a predictable and fair way. Suppliers need to recognise that they are delivering continuity and security of performance. Accordingly, expecting to be able to walk away at a moment's notice and without providing transitional support is unrealistic. Likewise, customers should not expect to get something for nothing, particularly at the point of exit when, almost by definition, in many circumstances the parties may not see eye to eye. Many customers complain that once a contract is signed, suppliers use the contractual change control mechanisms to vary aspects of the contract. Change control refers to the process by which parties agree to change the original contract. These changes are usually funded by the customer. Change control processes in themselves are not inherently bad, if correctly drafted. They should set out fast-track processes for some anticipated change, or even make some changes automatic within pre-agreed criteria. It is also important to distinguish between systems change and "true" legal change. Only the latter should involve the sorts of impact assessment and time-consuming discussions that give change control its bad name. If drafted and used correctly, the change control process is the device for ensuring that the contract delivers both certainty and flexibility. Consider all relevant aspects. Are employees affected? Do you need to consider issues of Tupe and transfer of employees to a supplier? Are there any third-party contracts or third-party software suppliers that need to be dealt with. Again, this can become a massive issue particularly in large services-based contracting relationships. If left to the last minute, this can either scupper the deal or cause significant delays. If disputes do occur, sort them out rapidly and move on. Don't let them fester and destroy the working relationship and, ultimately, the contract itself. Include an escalation process in the contract, and think about mediation and arbitration. Above all, make sure that issues get escalated quickly to a level where a resolution can be reached. Companies which go into an IT contracting situation without understanding the nature of the balance between contract control and flexibility are likely to find that problems exist. E-mail: [email protected] Alistair Maughan, partner at technology law firm Shaw Pittman, preaches 10 lessons you should obey when drawing up a contract for IT services







Marriage Vows


Understand the releationship


Plan for change






Aim for certainty


Integrate the contract






Use lawyers correctly


Plan for exit




Beware change control




Think about everything


Dealing with disputes




Alistair Maughan is a partner at Shaw Pittman, a law firm specialising in technology contracts

Read more on IT risk management

SearchCIO
SearchSecurity
SearchNetworking
SearchDataCenter
SearchDataManagement
Close