Getting IT partnerships right

When you enter into a partnership for IT solutions – either as an end user or as a solutions provider looking to find partners to suit your particular IT needs – it is crucial to get the arrangements right.Datacom is one of the large New Zealand IT solutions providers, and this company has seen a clear trend towards client demands, which makes partnerships inevitable. Scott Green, director of IT management, Datacom, says customers are increasingly engaging in good discussions about the agreements they enter into."We see an increasing desire from the customers for a single provider to provide them with a broad range of solutions from multiple partners,” Green says.Genevieve Gill, barrister and solicitor for the Auckland-based IT specialist law firm Genlaw, recommends preparing a full risk assessment and risk management plan for IT partnerships. "Such a plan enables parties to think through the various risks, develop risk mitigation strategies, and make informed decisions regarding where responsibility and liability sits,”  Gill says.Choosing partnership models for IT solutions inevitably require contracts to be signed. Not every IT contract warrants the same level of attention. Sometimes a quick review will be appropriate, sometimes it will not. The dollar value of the project is not always the only indication of the risks involved or how much time should be spent on the review, as a "mission critical” project may not necessarily have a large price tag.Key questions to askThe law firm Wigley & Company, which has a strong focus on IT and telecommunications, has put together a series of questions, which can help in the process for signing up to a contract for IT partnerships.Wigley & Company principal Michael Wigley states that it goes without saying that each IT project is different and requires a different contract. IT projects such as systems integration, outsourcing, and software development each have their own stand alone issues and risks that need to be addressed.But while he recognises a one-size-fits-all approach rarely works, these are some generic questions from Wigley & Company, which can be asked when an IT contract hits your desk:

1. What’s the deal? Even before diving into the detail of the contract it’s helpful to go back to first principles and consider the core commercial deal between the parties. Issues to think about include: What should the core obligations of each party be? What is the outcome that each party is looking for? Who else is involved? What processes need to be followed? What needs to happen and when? What are the deliverables? What are the dependencies?
2. Who are the stakeholders and what risks do they face? As well as dollar risk, risks to business, property, data, and even life will often need to be addressed. There may also be risks to third party suppliers, end users, the general public and "Dominion Post front page risk” to consider.
3. What’s the technology? Although the project will essentially be about delivering business benefits to both parties, there will be a technology layer that can have a substantial impact on what should and shouldn’t be included in the contract. Generating a list of the different technology components will usually highlight what other contracts are needed and whether there are additional issues and risks that need to be addressed.
4. How will this project affect other projects and our existing systems? Often one IT project will be part of a larger series of projects or will have an impact on existing systems. For example, the installation of new software or hardware may well end up voiding the support on existing hardware and software because of modifications and changes.
5. Where are the core obligations? Have the core obligations been captured in the agreement? Are they reasonable, achievable and clear? It’s not uncommon for some of the key obligations on a party to be lost in the noise of the agreement.
6. What are the standards of performance? What level of quality is expected from the deliverables supplied by the other side? This issue is normally addressed through the warranties that are included in the agreement. In this respect it’s helpful to consider the extent to which any quality or best practice standards should be incorporated. Often the benchmark for performance will include "compliance with the specifications” or "performance in accordance with the documentation”.
7. What’s in the specifications? The specifications for a project include the specific detail on what is actually going to be provided, and is often contained in a schedule, or a separate "Work Request” or "Statement of Work”. A lot of the risk in IT contracting lies in the specifications. Often, the terms and conditions of the head agreement get a close review but are undermined by loose wording in the specifications. It is common for there to be ambiguous descriptions and inappropriate use of legal words such as "guarantee”. The specifications should usually contain a clear description of the deliverables and include requirements around performance, functionality, capacity, response times, etc. It also helps to check whether or not the specifications should take priority over the main terms and conditions of the agreement.
8. What are the timeframes? When must each party’s obligations be completed? Is a delay serious enough to warrant termination of the agreement? Should there be liquidated damages?
9. Who gets paid and when? Does the payment schedule make sense? Should the prices be estimated or fixed? Should there be retention amounts? Should a delay in payment result in termination of the contract?
10. What are the remedies if things go wrong? Consider the remedies that are available to both parties if any of the obligations in the agreement are breached. There are various types of remedies that can be used, ranging from rights to terminate the agreement and sue for damages to service level rebates and step in rights.
11. What are we liable for? It is almost always appropriate for a party’s liability to be capped. If this is not done the cost of doing business can be prohibitive. For suppliers, the limitations and exclusions of liability in an agreement can be some of the most important clauses. Also, whenever there’s an obligation on a party, it may be appropriate for exclusions and exceptions to be included. For example, it’s not usually reasonable for a software supplier to be liable for any problems with its software where those problems have been caused by customer modifications or additions that it hasn’t first approved.
12. Who owns the intellectual property? Does each party own, or have the rights to use, the intellectual property ("IP”) that it needs? The ownership and licensing of IP is almost always one of the big issues in IT contracts. It’s easy for IP to fall between the gaps and for IP clauses to contradict each other. On the practical front, consider the format in which any IP should be delivered (e.g. by email, on CDROM etc), whether the source code to any software is to be supplied, and who will own any work in progress.
13. Where’s the IP indemnity? If a party is receiving any IP from the other party then it’s almost always appropriate for the supplier of the IP indemnify and defend the other party against any claim that its use of the IP infringes another person’s IP rights.
14. What happens at the end of the project? There may be a need for a transition process at the end of the project to help hand over the provision of the services and deliverables to the customer, or its alternative services provider. Similar processes may be required if the agreement is terminated. There will also often be the need for ongoing support and maintenance services at the end of the project.
15. Where are the acceptance tests? It’s usually appropriate for there to be some kind of acceptance tests to confirm whether the deliverables have met the appropriate standards, when the warranty period should commence, and when payments should be made. Acceptance criteria for these tests should usually be agreed up front so that there is a clear benchmark for the performance of the tests.
16. Do the processes reflect reality? Do the processes within the agreement reflect what is going to happen in practice? For example, boilerplate provisions around acceptance testing and change control (two important ingredients in an IT project) may require a procedure that’s not in your interests or that won’t work in practice. Different methodologies and processes in the supply of IT services and technology will also impact on what needs to be in the contract. For example, in the context of software development, the choice between the use of a waterfall or an agile software development methodology will have implications on how the contract is drafted.
17. Do the metrics make sense? There will often be service levels and performance metrics that need to be checked, particularly in the case of support and maintenance services. In particular, it helps to check the calculations that are used and whether there’s clarity as to what is being measured.
18. Are the definitions OK? Almost every IT contract contains a definitions section at the start or the end of the agreement. These definitions form the backbone to interpretation of the contract and need to be carefully checked. For example, the definition of "Intellectual Property” may refer to intellectual property that is created both before and after the commencement of the agreement – this may or may not be appropriate in the circumstances. Also, the definitions may not be used consistently in the schedules.
19. What happens if there’s a dispute? It is almost always appropriate for there to be some sort of dispute resolution process in the contract.
20. Finally, what’s missing? A good question to finish on, particularly if dealing with a contract that has been prepared by the other side.