How to make other people run your IT smoothly

Drafting the tender document – know what you need and set your requirements out in full in the tender document. You might want to insist that the preferred supplier act as prime contractor, thereby avoiding the need for you to contract with a number of different suppliers. Obtain a copy of their standard contract at the outset – this will give you a flavour for the extent of negotiations which are likely to ensue.

Choosing the right contractor – make sure that your selection criteria focus on what really counts. Be realistic about what’s important and what’s not. Seek references from other customers – don’t rely on the word of the salesman alone. Depending upon the complexity of the systems being outsourced, consider appointing a consultant to help you make the right choice. Depending on your needs you may feel safer selecting a larger contractor even if it means losing some flexibility. Alternatively if flexibility is key, you may be prepared to accept reduced response times, and select a smaller contractor who is prepared to make changes just to suit you.

Duration – if the contract is to run for a five-year term, ask whether that means five years from signing or five years from the go-live date? Be clear about this at the outset – it can make a big difference to the commercial discussions.

Compliance – transferring data to another contractor is going to give rise to often-complex data protection issues. You will need to check the terms of your existing customer contracts to determine if such transfers are allowed, and, if existing contracts don’t anticipate transfers of this type you will need to consider how to complete the exercise and stay on the right side of the Data Protection Act 1998. There may be other compliance issues depending on the nature of your business, for example, in connection with the Financial Services Act. These will all need to be addressed before the outsourcing contract can be finalised.

Confidentiality – all those invited to tender should sign confidentiality agreements. It might be appropriate to make the commercial terms of the contract confidential, and some aspects, such as customer information, should remain confidential even after the contract expires. Consider whether the relationship itself should be confidential or if you are happy for the deal to be publicised. If you are, make sure that you get to approve the terms of any press release in advance.

Service level agreement (SLA) – once the contract is up and running this is the document against which performance will be judged. Agree at the outset what response times you expect. Also consider whether some faults may be less time-critical than others. Be realistic – 100% uptime is unlikely to be possible – make sure you know what the industry norm is. What happens in the event of continued service level breaches? Will rebates be enough or do you want the option to terminate? Allow for continued improvements in the service levels during the life of the contract. The arrangement might be competitive today but it needs to remain competitive throughout the term.

Specification – if bespoke systems are being provided or standard systems with bespoke elements, be sure that the specification for those systems sufficiently describes your needs. Avoid any ambiguities so that it is clear what has been agreed. Agree who is paying for any bespoke development work and who will own intellectual property rights in the finished product. Also agree the process for identifying any gaps which the development work might need to plug.

Warranties – these are likely to be the subject of much negotiation. Warranties that the system will perform in accordance with the specification or that the service levels set out in the SLA can be achieved on the basis of a given IT infrastructure are likely to be appropriate. The contractor is unlikely to own all aspects of the system, which may well rely on some third party software – include a warranty that all appropriate licences and consents are in place in respect of that third party software, and that they will continue to be for the duration of the term.

Indemnities – agree what indemnities the contractor will provide. Make sure they cover, for example, loss of data, breach of confidentiality or infringement of third party intellectual property rights – essentially, those matters outwith your control.

Limitations on liability – what limitation are you prepared to accept and are you prepared to accept it for all liabilities or might there be some cases where no limitation is appropriate – for example, loss of data?

Intellectual property rights – often the contractor will want to retain ownership of intellectual property rights even in bespoke elements of the system. If so, make sure that source codes are deposited in escrow and if you don’t get to own rights in the system, make sure that’s reflected in the price. If third party licences are in place, make sure that the contractor has to replace those licences if they fail, and that they have to do so at their own cost and without interrupting business continuity.

Dispute escalation – during the lifetime of the contract disputes are inevitable, for example when deciding if service levels have been met. The parties should adopt a pragmatic approach to resolving these disputes, so clear procedures for managing disputes should be agreed and documented in the contract.

Key personnel – once the project goes live you don’t want to find that the people you’ve spent months building relationships with disappear off to work on the next project. So make sure the contract identifies key personnel who must remain committed to the project for the duration of the term. If they leave make sure you are involved in recruiting their replacement. Identify contract managers for each party and, to ensure the effective management of the contract, agree regular review meetings.

Change control – one of the most likely areas to cause disputes is change control. While the contractor might agree to quote for any change you require, you need to have mechanisms in place to ensure that you don’t get held to ransom. If the quote’s not competitive, depending on the importance of the change, you might need the right to terminate.

Exit management – these contracts take a lot of time and money to negotiate and agree. Having invested that time, you don’t want to have to reinvent the wheel next time around. This means that on termination the contractor should supply you with enough information to take to the alternative contractor to avoid them having to start from scratch. You need to ensure that the notice periods allow sufficient time to put an alternative contractor in place.

Implementation – identify what’s involved in the transfer and agree milestones for performance. Consider if liquidated damages are appropriate. You need to get your data onto the contractor’s system. The process of data migration can often be complex and costly. Agree at the outset who is going to pay for this exercise and for any work which needs to be done to ensure a smooth migration.

Testing – at whose cost, using whose data and against what criteria will acceptance testing take place. These matters will all be relevant in the context of testing and unless the obligations of the parties are clearly spelt out it can be a fertile ground for dispute. Make sure testing takes place in a controlled environment without using live data.

The above list is not intended to be exhaustive but illustrates the sort of matters a typical IT outsourcing contract might want to address.

Lisa Sinclair, Brechin Tindal Oatts