Background Papers

Drafting Secure IT Contracts

By: James Date: February 22, 2016

Introduction

As the boundaries of technology and communication expand, computers and other technological devices are increasingly part of the economy. As businesses and users install and use more complex IT systems, the need for secure contracts with suppliers has increased. Correspondingly, suppliers need to avoid cash flow or project timetables being disrupted by contractual disputes. Suppliers need secure contracts that result in disputes being resolved quickly, fairly, and with certainty.

Most IT contracts relate to complex deals and circumstances. Examples of the subject matter of IT contracts include software development, hardware supply, software licensing, systems integration, outsourcing, provision of hosting services, etc. Although IT contracts cannot cover every issue that may arise, they can deal with and manage the risks arising from IT contracts so that the adverse consequences of a dispute or failure are minimised.

In this paper we will discuss:

Common problems with IT contracts;

What you need to consider before entering into an IT contract;

How to improve your IT contracts;

Key terms and conditions found in most IT contracts;

The benefits of proper project management procedures; and

Commonly overlooked issues.

IT Contracting Problems

Consequences of Failure

IT projects are recognised as prone to failure, and that failure can cost businesses enormous amounts of money and loss of other benefits. In addition, more and more cases of IT project failures are being litigated or brought to arbitration – both expensive and time-consuming methods of dispute resolution. Consequences of failure of IT contracts include:

Bankruptcy or liquidation of a contracting party;

Failure of mission critical systems;

Damage to brands and reputation;

Loss of ongoing business;

Destruction of the value of the product (eg, consumer reluctance to buy products because they are “buggy”); and

Loss of career of the executives involved.

Given the current competitive marketplace, these consequences are not acceptable. It is important to understand the causes of failure of IT contracts, so that these scenarios can be avoided.

Common Causes of Failure

Getting the basic requirements in contract law wrong

A common flaw when contracting for IT is that the parties fail to establish a clear structure for their contractual relationship at the outset. This means that from the beginning each party may be negotiating under different assumptions as to their responsibilities and duties.

Contracting with parties that lack authority

Often systems involve software from overseas. A frequent cause of problems is where the local reseller purports to contract for modifications on a basis that is not supported by the overseas software house’s licence. This is a complex area but issues to watch are:

The reseller offering copyright title to modifications when the licence requires that those modifications pass back to the software house;

The reseller offering “free seat” or client licences in contravention to the licensor’s licence scheme; and

The reseller agreeing to warranties that it cannot perform.

Multiple contracts – Inconsistent terms

Whenever a project requires multiple contracts (for example, hardware, software and services) it is common for parties without legal advice to end up with multiple contracts containing conflicting clauses. When read as a whole these contracts are often confusing and ineffective.

Interrelated contracts must be carefully drafted to ensure that the obligations of the parties are clear and consistent.

Supplier standard contracts will be interpreted against the supplier

It is a well-established legal principle that specific words in a contract (eg, those clauses limiting or excluding liability under the contract) are construed against the person for whose benefit they are inserted.

A supplier using a standard form contract must be aware that if the Court believes there are ambiguities or inconsistencies, then it will interpret the contract in favour of the customer. This is more likely if the supplier is a large commercial enterprise dealing in that particular form of contract.

A customer accepting a standard contract at law, however, cannot simply assert that it is a recipient of a standard contract, which should therefore be interpreted against the supplier. The Court will look at the commercial sophistication and the bargaining power of both parties.

Lack of proper project management and dispute resolution

We note that:

Change requests are an inevitable part of complex IT projects. Unless the contract is clear as to the extent of allowable variations and the rights of each party to initiate or object to a change, any changes made can be argued as a breach of contract.

Contracts that exclude effective dispute resolution are prone to lengthy delay periods whenever minor problems arise. If the process for problem solving is clear and unambiguous, then parties can avoid expensive delays or renegotiation.

Rushing into the project

Often work starts on the project before the contract has even been signed, and the parties may intend to define key supply terms (eg, acceptance test criteria) at a later stage. However, these terms (eg, acceptance testing) are an essential part of the contract and should therefore be resolved as soon as possible.

Acceptance test criteria should either be defined at the outset, or the parties should look at alternative approaches such as phased projects, agile programming, etc. Of course, it may not be possible to define anything at the outset of the project. This should, at the least, be recognised by the parties and provided for where possible.

What You Need to Consider

The aim of any contract drafting process is to ascertain and accurately record the intention of the contracting parties. Before entering into an IT contract the parties need to determine basic aspects of the contract, including:

The object of the contract and related objectives of the parties;

The form of the document (ie, agreement or deed?);

Necessary parties to the contract (or, at the least, whether contract privity statements need to be included);

Whether it is appropriate to form a joint venture, partnership or similar relationship between the parties for the purpose of carrying out the project (this may encourage a more positive approach to the project by all parties, but carries various risks and benefits);

The effect of the contract on your other existing contractual relationships (eg, telecommunication companies – do you have a MFS (most favoured supplier) clause that requires you to first offer any new communications needs to your existing supplier?);

The legal effect of the contract on you and the other party – in particular, suppliers need to guard against guaranteeing the impossible;

Access to other parties’ information and/or resources;

Pre-contractual representations and whether the contract is intended to capture the “entire agreement”;

Necessary content to address (or to provide a definite process for addressing) foreseeable events under the contract;

Potential liability claims against you and what protection is afforded by the contract;

Your ability to vary the contract; and

Methods to ensure the project is completed in the quickest possible time (eg, project management groups and appropriate dispute resolution clauses).

In the rush to complete deals, many of these basic questions are often overlooked.

How to Improve Your Contract

The following are some general guidelines that may assist in preparing an effective contract.

Core Provisions

The core provisions of the contract are those that affect the contractual relationship as a whole. They go to the root of the contract’s operation. These are discussed further below.

Modular Contracts

Modular contracting allows for components to be added or removed to suit the range of activities under the contract.

The benefits of drafting contracts in this way, especially for IT contracts, is that it allows you to separately negotiate individual components such as software licensing or service level agreements and achieve progress by locking down the less contentious or less detailed areas so that everyone can focus on the more important and often difficult issues.

Dispute resolution and project management are deliberately included as “modules” in major projects as these areas may require substantial tailoring of the standard text to ensure that the terms correspond with the way the project will actually be run.

Avoiding Legal Jargon

Frequently, once a contract is signed, it is filed away out of sight, only to be referred to once a dispute arises. However, an effective contract should be a road map for the parties throughout the relationship. Use of plain English in drafting assists in achieving this goal.

A contract that requires the lawyers to explain what the words mean every time the parties want to use the contract is not a contract that will be “owned” by the parties. Legal jargon is not necessary and is a sign of poor drafting and a failure to get to grips with the real issues for the parties.

It is also important to make sure that the contract is practically correct (ie, that the contract accurately reflects how the parties will operate).

Forms and Check-Boxes

Use of fill-in-the-blanks forms and check boxes allow the contract to be easily tailored to the needs of each individual contractual relationship.

This style of drafting also increases the “buy-in” to the documentation from all parties. It is well understood that where a contract is completed by hand, by filling in boxes on the supplier’s standard terms, the customer attributes higher credibility to the hand-completed sections.

Core Terms and Conditions

Key terms and conditions found in most IT contracts include:

Recitals/Background/Introductory statements

Recitals generally explain the background to the contract and clarify representations or assumptions that may have been relied upon by the parties when entering into an agreement. They perform a different function to the “operative” provisions of the contract. Although not part of the legally binding terms between the parties, they are a relevant snapshot of the circumstances in which the contract was prepared and have long been recognised by the Courts as a valid aid to interpreting the operative provisions.

Exclusions/Limitations of Liability

A contract may incorporate a limitation of liability clause in relation to damages arising from a breach of the agreement of from the negligence of one party in the performance or failure thereof.

These clauses are essential in the IT industry as losses can far exceed the cost of the good or service that causes the loss. As an example, a disk or drive may be relatively inexpensive, but holds very valuable company information. If the disk/drive were defective, the loss suffered by the company as a result of losing the information on it would far exceed the cost of the disk/drive itself.

The Courts have traditionally been hostile to exclusion or limitation clauses, although in more recent case law this approach has diminished, with the focus now being placed on the extent of the protection and some consideration of the commercial realities.

The Courts will construe limitation clauses strictly and contra proferentum (ie, in the manner least favourable to the party seeking to rely upon them), however, the degree of strictness may vary with the extent of the exemption conferred by the clause. Commercial realities such as the knowledge and bargaining power of the parties are also taken into account when interpreting these provisions.

Care should be taken to make the ambit of the exclusion clear and record that it survives termination.

Other options which may be introduced by the supplier are:

(a) Placing a limitation period on the time for the commencement of proceedings;

Liquidated Damages and Performance Rebates

These clauses can avoid problems when determining damages for breach of contract. We note the 10% rule of thumb, ie, 10% of the value of the contract is generally viewed as a “reasonable” sum to be paid as a non-recoverable deposit in the event of non-performance. If potentially above this amount, care must be taken to ensure that the clause appears (and in substance is) a genuine pre-estimate of damages. It is often useful to adopt a formula that, in some way, endeavours to reflect the damages that flow from a breach, and couple this with acknowledgments that this is the intention of the parties.

A Court may well seek to estimate the common law damages that flow from breach, based on factor apparent at the time the contract was entered into, and compare the result with the corresponding provisions to determine whether the clause operates in a penal manner. The Court will not enforce a provision that seeks to penalise the party in breach (rather than compensating the innocent party).

Tax Implications

It is important to be aware of the tax implications arising out of a contract, including:

Income tax;

Withholding tax;

Double taxation agreements; and

Goods and services tax. The liability to pay GST generally lies with the supplier of goods or services, so the supplier needs to ensure that the contract price includes the amount that the supplier will be liable to remit as GST.

It is reasonably common for contracts to specify that one party or the other will bear the cost of taxes imposed in respect of goods or services which are the subject of the contract.

Termination

A termination clause should set out the rights and obligations of each party in the event of termination. A contract may provide that, in the event of termination:

The terminating party may recover the amounts (or a proportion thereof) paid for the goods; and/or

The service provider may complete the works in question (or perhaps complete just the tasks currently under action) or, alternatively, that the customer may engage a third party to do the same; and/or

Activate any financial guarantees; and/or

Immediate return of confidential information.

Regardless of the terms of the contract, parties also have the rights of cancellation set out in the Contractual Remedies Act 1979.

Conflict of Interest

Conflict of interest clauses generally involve an undertaking by one or more parties that its/their involvement in the transaction will not result in a conflict of interest which could compromise its ability to fully and faithfully discharge its obligations.

The question then becomes, what amounts to a conflict of interest? This should be carefully considered and defined in the context of the laws relating to restraint of trade.

In some circumstances, the Courts will be willing to imply an obligation that parties to a contract must not neglect the other contracting party’s interests in favour of pursuing their own competitive interests. Any specifically inserted clause should seek to enlarge and clarify this obligation.

Dispute Resolution

Properly considered and drafted consultation and dispute resolution processes can assist considerably in achieving a commercially successful contract. In conjunction with suitable indemnities and other clauses, these processes can:

Assist in maintaining and developing the business relationship between the parties;

Provide strong legal incentives to operate in accordance with the contract (and strong disincentives for the parties to breach the contract);

Provide an informal, efficient and confidential mechanism for resolving disputes that arise; and

In appropriate circumstances, categorise disputes and provide for differing processes to resolve each. This approach recognises that some disputes are so fundamental that attempting resolution (other than by voluntary agreement of the parties) is not possible or appropriate.

A good dispute resolution clause should provide for escalation of disputes. When parties are faced with the alternatives of formal legal processes such as Court or arbitration, following an informal dispute resolution process at the outset is almost always worth the effort from a commercial perspective. This can involve escalation of the dispute from management to CEO or chairperson level is not resolved within a set period, and can be assisted or supplemented by a facilitator or mediator, which could be particularly useful if the parties have an ongoing business relationship. Another option for resolving a dispute quickly is determination of the dispute by a suitably qualified industry expert.

Boilerplate clauses

Boilerplate or “foundation” clauses are often viewed as clauses of general application to any subject – this is not, however, strictly correct.

Common boilerplate clauses include:

Time of the Essence: Used where time frame is critical (eg, settlement, project launch, ‘go live’, etc).

Confidentiality: Inserted to prevent unauthorised user disclosure of knowledge gained in the course of dealings.

Privacy: Distinct from confidentiality, and arises in specific situations involving the transfer of personal information (as defined in the Privacy Act 1993).

Force Majeure: This type of clause exempts a party from the obligation to complete the agreement in circumstances of an unexpected disaster, making performance by that party impossible.

Prohibition on Subcontracting: A prohibition on subcontracting is often in the customer’s best interest (ie, controlling the identity of the suppler, ensuring quality of product/service). Where subcontracting is permitted subject to the other party’s consent, it is usual for such consent to be “not unreasonably withheld”.

Prohibition on Assignment: Suppliers will sometimes prefer to restrict the circulation of their product in the marketplace in order to enhance the prospect of further deals. Depending on the circumstances, it may be appropriate to prevent assignment by one party but not the other.

Entire Agreement: An acknowledgment that the executed contract supersedes all prior representations, agreements, etc. Where adopted, it is important to incorporate all written representations into the contract.

Waiver: A waiver clause is inserted to minimise the prospect for any argument that rights had been waived through the party’s actions.

Variation: These clauses often provide that variations are not valid unless acknowledged in writing by both parties.

Co-operation: One or more parties undertakes to do all things necessary to give effect to the agreement.

Survival of Agreement: A survival clause will generally provide that a certain covenant remains in full force following the expiration of the agreement.

Severability: This is a clause which stipulates that a contractual provision which is illegal, invalid or unenforceable can be severed from the agreement without affecting the validity of the remaining provisions.

Precedence: This clause prioritises components of the agreement (or a series of agreements) fore the purpose of interpretation – generally, such a clause would provide that inconsistent provisions lower in the order of priority will be deleted, but only to the extent necessary to resolve the inconsistency.

Governing Law and Jurisdiction: Although the parties are largely free to agree upon the governing law against which the contract will be interpreted, they have less latitude to agree the appropriate forum for the dispute to be resolved. Courts may override an express provision where the choice is not bona fide or on public policy grounds. Parties should also consider issues such as whether the jurisdiction should be exclusive or non-exclusive, and whether the submission to the jurisdiction should be one-way or reciprocal.

Notices: Notice clauses add to certainty in service/notification under a contract. In the absence of a notice clause, there is a greater possibility of dispute arising where service or notice is made other than by personal service.

Counterpart execution: Where an agreement provides that it may be executed in counterparts by the respective parties it will be deemed to be validly executed if each party holds a copy signed by the other even though neither copy may be signed by both parties.

Non-merger: Merger occurs when a lesser right is “merged” into a greater right when the greater right is subsequently acquired. This principle can cause all of the terms and obligations under a contract to terminate when the main transaction under a contract is completed. A non-merger clause will seek to prevent this automatic termination of clauses which are intended to survive the completion of the main transaction contemplated by the contract,

Project Management

IT projects are often complex, involving resources that cross the customer’s departmental boundaries and require high levels of cooperation between the parties. To ensure cohesion and efficiency, a management body for the project should be established to supervise the project. This will ensure that the project is not hindered by lack of resources and the parties can jointly deal with any queries and make decisions quickly.

Project management has emerged since the 1970s as a profession in its own right, and project management (as a body of knowledge) encompasses several issues which are relevant to an IT contract, including:

(a) Risk identification, apportionment and management;

(b) Resourcing and ordering process;

(c) Delivery, including critical path analysis and timing/deadlines for interrelated steps in a project;

(d) Changes to the project mid-term, and ensuring stakeholder participation and “buy-in” to variations.

The most detrimental problem any project can face is lack of management. Where the contract relates to an IT project and includes deliverables or milestones, it may be appropriate for the contract to include project management provisions.

Risk Management

There is an extensive body of resources dealing with the analysis and management of risk. In the project management field, “risk management” is the art of managing risks to achieve the successful completion of the project, with major components of risk management recognised as:

(i) Identifying sources of risks;

(ii) Analysing and assessing risks;

(iii) Responding to the risks;

(iv) Contingency planning; and

(v) Establishing contingency reserves.

If the contract is intended to capture an ongoing project where variations are a real prospect (or indeed inevitable), or where it is impossible to accurately scope and document the necessary steps in the process through to completion of the project, then consider the use of a “Project Control Group” (“PCG”) or “Project Steering Committee” (“PSC”).

Use of a Project Control Group

A PCG is responsible for overseeing and modifying the various projects governed by a contract.

Implementing a formal PCG process can be an excellent method of enabling all contractual stakeholders to monitor the supply and implementation of the project deliverables. A PCG usually has a minimum of two representatives from each side, and normally includes key persons involved in the project (although all PCG members who are not officers or employees of the contracting parties should sign confidentiality agreements).

Examples of appropriate PCG objectives are:

(a) To define the tasks arising out of the agreement and timetabling those tasks (perhaps by reference to a project plan);

(b) To oversee the supply and implementation of the [insert project deliverable here] and the completion of tasks specified in the project plan; and

(c) To process “change requests” including preparing a change request specification in the form prescribed by the parties.

The authority of the PCG should be clearly defined and demarcated, and the operational aspects of the PCG should be agreed and documented, eg, voting rights, frequency, quorum and proceedings at meetings, etc.

A major function (and major benefit) of a PCG or similar is the processing of “change requests”, being changes to the scope or detail of the deliverable or the main contract itself. A distinction can usefully be drawn between substantial and other changes sought by one or more parties. The PCG can have decision-making rights (generally where the issue is not substantial) and can also have the power to make recommendations in other cases. The contract should record the process to notify, consider, agree or determine, and document any “change requests” under the contract.

Obviously these issues should be documented with sufficient detail, but it is also very useful (to assist the ease of comprehension when the parties refer to these processes in the future) to include a diagrammatic representation of the process (a tool useful in many contract situations). Other useful tools include Gantt charts, project plans, and escalation procedures.

Use of a Project Steering Committee

Another commonly used management structure is that of the PSC. The role of the PSC includes reviewing and monitoring the progress of the project and reporting to the management of the customer.

A PSC differs from a PCG in that under the PSC methodology there are individual project managers for the supplier and the customers, rather than a single person or group. These managers operate independently of each other and focus only on their respective group’s interest.

Use of a Project Sponsor

Another common method for managing the implementation of a project is a Project Sponsor. A Project Sponsor is a person within the customer’s business who maintains ownership of the project, and is part of the project’s management body.

As the owner of the project, the Project Sponsor is the person who ultimately has to make or take responsibility for the hard decisions of the customer. This is particularly true if the PSC structure is adopted. If, however, a PCG framework is established, then the pressure on the Project Sponsor to make key decisions is reduced, as the responsibility for implementation is on the PCG as a whole.

The benefits of adopting a PCG approach to project management is that more than one person is charged with providing solutions and the role of the Project Sponsor moves away from being the decision maker to that of a general manager or overseer.

Commonly Overlooked Issues

Relationship Between Insurance and IT Contracts

Under general project insurance policies, the insurance company must be notified of any changes in the project agreement within a set period or the policy is void. These general policies often make it difficult to alter the agreement without having to make costly changes to the policy. In addition, insurance policies often do not recognise the need in an IT contract to quickly and effectively settle disputes.

Most policies provide that an admission of liability will void the policy. Furthermore, cover will be prejudiced for not “notifying” the insurers immediately when a dispute arises. As a result, if a supplier agreed to fix something in a project control meeting, the cost of doing so will not be recoverable from the insurer – despite the fact that this action may reduce the supplier’s liability in the long term.

Both suppliers and customers often overlook insurance when entering into large and expensive IT contracts. The exposure to the risk of damages or repair costs after paying hefty premiums arises because of the failure to properly draft the project management sections of the contract to integrate the contract with the requirements for “notification” under the insurance contract.

Also, IT-specific policies should be taken out that recognise change and industry methodology such as project management groups. By doing so, you can limit the possibility of your insurance policy refusing to pay out on project policies.

Discovery

Discovery is a legal process that enables one party to obtain evidence (such as letters or emails) from another person that relates to any legal proceedings. When a supplier and a customer enter into an agreement, and the supplier has a teaming or sub-contracting agreement with another party, then any correspondence between the supplier and that other party will be discoverable by the customer if relevant to the legal proceedings between the supplier and the customer.

Therefore, when discussing customer relationships with teaming partners and the like, you need to be aware that, if a dispute alter arises between you and your customer, your customer may be able to obtain copies of these sensitive documents through discovery.

Learning from other industries

The law applying to IT contracts is not new – it is merely the adaptation of existing principles to a new industry created by technological advances. When drafting IT contracts, principles from other industries should be utilised to ensure that the contract is secure.

For example, there are well-established principles in the construction industry relating to the areas of project management, variation of contract and issues raised by sub-contracting.

Further Information

This paper discusses some very specific issues. We have not addressed the fundamentals of contracting, which include:

Intention to create binding legal commitments;

Offer and acceptance;

Capacity to contract – if a party does not have authority or is too young or mentally unstable to contract for what it promises, it may not have “capacity”.

There are also several key statutes governing contract law in New Zealand, including:

Illegal Contracts Act 1970;

Secret Commissions Act 1908;

Sales of Goods Act 1908;

Fair Trading Act 1986;

Consumer Guarantees Act 1993;

Contractual Mistakes Act 1977;

Minors Contracts Act 1969;

Contracts (Privity) Act 1982;

Sale of Goods (United Nations Convention) Act 1994;

Contractual Remedies Act 1979;

Arbitration Act 1996.

Disclaimer

This Background Paper by its nature cannot be comprehensive and cannot be relied on as legal advice, but is instead provided to assist readers to identify legal issues on which they should seek specialist legal advice.

Please consult the professional staff of Clendons for advice specific to your situation.