You are on page 1of 36

Chapter 2

Software Contracts and Liability

Information Systems p. 26/149

Introduction
Well now have a look at an area youre likely to encounter in some way or another when working in IT Contracts in the IT industry We give a brief overview of contractual arrangements in the IT sector Also sketching implications that the different contract types have Have a brief look at liability for defective software

Information Systems p. 27/149

What is a Contract?
A contract is simply an agreement between two or more persons Can be enforced in a court of law Parties involved may be legal persons or natural persons Legal person: legal entity that has the capacity to act, can acquire rights and create obligations (separate from its members) No specic form: in England and Wales a contract need not be written down

Information Systems p. 28/149

What is a Contract? (2)


Essential points of a contract All the parties must intend to make a contract All parties are legally competent (i.e. old enough, of sufciently sound mind) There must be a consideration: each party receiving/providing something Contract law is largely based on common law However, here we focus less on law but more on typical content of contracts

Information Systems p. 29/149

Types of Contracts in IT
Well be looking at Development of tailor-made (bespoke) systems Fixed price contracts Time and material Consultancy and contract hire Outsourcing License Agreements

Information Systems p. 30/149

Fixed Price Contracts


Usually contains the following three parts Short agreement: species parties, excludes anything written or said from before the contract Standard terms and conditions: normally those under which supplier does business Set of schedules or annexes specifying What is to be supplied and when What payments are to be made and when etc.

Information Systems p. 31/149

What is to be Produced
Usually standard terms refer to annex which in turn refers to requirements specication document Ideally, the requirements specication is complete consistent accurate In the real world very difcult to achieve Often different versions of requirements are oating around, correct one needs to be referenced in contract Well come back to handling change in a moment

Information Systems p. 32/149

What is to be Delivered
This is usually not simply handing over some les/documents containing programs Contract has to state explicitly what changes hands, this can include Source code Command les and scripts for building executables and deploying them Documentation of the design and the code Manuals for reference, training, operations Maintenance tools User training Training of clients maintenance staff Test data and results
Information Systems p. 33/149

Ownership of Rights
Usually straightforward for tangible assets such as hardware, documents, data storage media Legal rights are passed from supplier to client Much more difcult for intangible assets such as intellectual property rights This is an important topic of its own, well discuss it in a separate chapter Important here: contract should state precisely who owns which rights

Information Systems p. 34/149

Condentiality
Very hard to avoid that supplier and client will acquire condential information during development process Supplier may learn about internal processes of client Client may nd out details about specic development methods used by supplier Usually both parties agree in the contract to maintain condentiality about these matters

Information Systems p. 35/149

Payment Terms
Normally, standard terms and conditions specify payment conditions E.g. payment within 30 days of invoice, if payment is delayed, supplier may terminate contract or charge surcharge (e.g. base lending rate + 2%) For long-running projects it is more realistic to have a payment in stages, for example Initial payment of 15% (due on signing the contract) Further staged payments totaling 50% on reaching certain milestones 25% on acceptance 10% at end of warranty period

Information Systems p. 36/149

Payment Terms (2)


Reasons for staged payments Protects supplier from certain nancial risks (e.g. insolvency of client) Reduces cash ow difculties on supplier side (staff have to be paid) Usually involves some negotiation Supplier prefers staged payments corresponding to calendar dates (allows better planning) Client favors tying them to project milestones (doesnt want to pay for unnished work)

Information Systems p. 37/149

Delays
Software development projects are notorious for being delayed and late Normal mechanism for delays on supplier side are penalty clauses Penalty clauses usually reduce the sum payable to the supplier by a specied amount per agreed time span E.g. for a contract value of 1,000,000 penalty might be 5000 per week up to a maximum of 100,000

Information Systems p. 38/149

Delays (2)
As delays in development projects are a well-known fact, one would expect hefty nes However, not that common for xed price contracts Delays already eat into prot margin of supplier, so there is already an incentive to nish on time As a consequence suppliers will be reluctant to accept harsh penalty clauses If penalty clauses are included, this usually drives up the bid price If software is seriously late and penalties approach their maximum, the incentive to nish drops Supplier will have likely maxed out (staged) payments they will get
Information Systems p. 39/149

Delays (3)
Delays can also be caused by the client Failing to provide required information on time Change requests that result in extra work Contract should provide clauses for calculating costs and extra payments Payments for delays and variations to original requirements often lead to disputes (and even legal action) This is not restricted to IT sector, construction industry seems to be notorious Sometimes used as a mechanism to increase prot margin after over-competitive bidding

Information Systems p. 40/149

Clients Obligations
Due to the hassles this can cause, it makes sense to specify the obligations of a client in the contract These can include (but are not limited to) Provide documentation on relevant activities of the client on the environment that system will run in Provide access to appropriate members of staff Provide facilities for development and testing Provide accommodation, telephone, secretarial, and other facilities for staff working on clients premises Provide data links to the site

Information Systems p. 41/149

Project Management
Parties must also agree on which standards, methods, quality assurance procedures to use Supplier and client may have different views on this arranging meetings to report (and record) progress and completion of milestones who is responsible for running the project on supplier and client side and specifying the authority of these persons

Information Systems p. 42/149

Acceptance Procedure
Critical part of a xed price contract, as this denes criteria for successful completion Ideally, client supplies a xed set of acceptance tests and expected results Adding extra tests later only by mutual agreement (otherwise this introduces delays and moving targets) Should also specify who monitors the tests and what happens if tests fail to complete successfully

Information Systems p. 43/149

Warranty and Maintenance


Common practice (after product has been accepted): warranty period of 90 days All errors found and reported within this period will be corrected free of charge Often open to negotiation: the longer the warranty period, the higher the cost Once warranty expires, supplier may offer maintenance (available on request) This often involves modifying or enhancing a systems capabilities Therefore rarely handled on a xed price basis, but on time and materials (details on this later)

Information Systems p. 44/149

Other Clauses
Ination: long-running projects may have a clause on how charges increase with the rise in costs Indemnity: one party may cause the other to infringe a third partys rights (e.g. intellectual property) Each party guarantees to cover any costs for liability arising from its own faults Termination: for risky or long-running projects one party may want to get out of a contract Clauses have to specify when and under which circumstances this is possible

Information Systems p. 45/149

Other Clauses (2)


Arbitration: in the case of a (legal) dispute, an appearance before court may become very costly, possible alternative could be arbitration Parties agree to accept the decision of a neutral third party: an arbitrator In the UK, the BCS or IET maintain lists of qualied persons, which they appoint Applicable law: especially important when supplier and client have registered ofces in different legal jurisdictions Contract states under which laws it is to be interpreted In case contract exists in more than one language, also states which version is legally binding
Information Systems p. 46/149

Other Types of Contracts


A xed price contract shifts most of the risk to the supplier If the requirements of a system cannot be specied sufciently enough, then a supplier wont tender a bid for xed price charge an inordinate amount of money There are other types of contracts that share the risks differently Contract hire Consultancy Time and materials (also called cost plus contract)

Information Systems p. 47/149

Contract Hire
Supplying the client with the services of a certain number of staff at agreed rates (daily/hourly) Client takes responsibility for managing staff Supplier is responsible for supplying suitably competent people Either party can terminate contract at fairly short notice (typically one week) Contract hire agreements are much simpler than xed price contracts Many issues, such as delay payments, simply dont arise Some, however, such as intellectual property rights, still have to be addressed
Information Systems p. 48/149

Consultancy
Consultancy projects can be done for a daily/hourly rate or at a xed price If done at xed price, contract is much simpler: Sums of money involved are usually much smaller The end product is very often a report, not an actual system Nevertheless, there are some important issues that need to be covered

Information Systems p. 49/149

Consultancy (2)
Condentiality: a consultant may not disclose information about client learned during assignment Terms of reference: specify which matters to investigate (and which not) Can become source of disagreement: consultants discover they need to look at issues outside of original terms Liability: consultants usually want to limit their liability (follow advice at your own risk) Client may insist on adequate liability insurance Ownership of nal report: client is often given a xed period to review a draft before handing over the nal report
Information Systems p. 50/149

Time and Materials


Contract hire shifts most of the risk to the client A time and materials contract tries to balance the risks between client and supplier Supplier agrees to the development of a system similar to a xed priced contract (i.e. requirements, delivery, acceptance, etc.) The payment, however, is handled differently Made on the basis of costs incurred Labor charged in a similar way as for contract hire Supplier does not have to deliver for a xed price (often maximum payment may be xed) Risks can be managed by agreeing on milestones and termination clauses
Information Systems p. 51/149

Outsourcing
Outsourcing is a contractual arrangement under which a client hands over a certain business function to a supplier This usually includes planning, management, and operation of this function Very common in some situations: few people generate their own electricity or drill their own wells Logic is that a company specializing in a particular area, e.g. catering or ofce cleaning, is probably better at it Helps an organization to focus on their core competencies

Information Systems p. 52/149

Outsourcing (2)
IT services are not that different, people and organizations have always purchased from third parties such as software package suppliers or software houses However, starting 20 to 25 years ago companies and governments handed over whole IT departments Software companies even started to outsource programming tasks

Information Systems p. 53/149

Outsourcing (3)
IT outsourcing contracts are usually very complex and depend on individual circumstances Important points that need to be addressed are Service level agreements: How is performance monitored and managed What happens if performance is unsatisfactory Which assets are transferred Staff transfers Contingency plans and disaster recovery Duration of agreement and termination provisions ...

Information Systems p. 54/149

Outsourcing (4)
Experience has been varied, but not all organizations were happy with the result Cost/benet ratio did not work out Losing expertise and control There has been a trend to insource services again Studies show that the effects of outsourcing have been overstated (IMF working paper 04/186) The US and the UK export more services than they import

Information Systems p. 55/149

License Agreements
When customers buy software, they buy a copy and the right to use it in certain ways In certain ways means: there are different types of restrictions in place Single user license: allows the use of one copy on one machine for one user Example: computer game Server license: software can be run on a server providing it to any number (up to a maximum) of users on a certain LAN Example: database server Site license: covers all the users of a system Example: MyBirkbeck
Information Systems p. 56/149

Liability for Defective Software


Almost all software contains some bugs You have probably seen statements such as XYZ shall not be held liable for any damage caused by the use of this software. or . . . can only be held liable to a maximum of the purchase price of this product. Does this mean that suppliers are off the hook? Not quite, enter the Unfair Contract Terms Act 1977

Information Systems p. 57/149

Unfair Contract Terms Act


A supplier may only restrict liability if its reasonable to do so If a product causes death or personal injury, its not possible to limit the damages payable This refers to software as it does e.g. cars Assume for a moment that software for controlling air trafc causes an accident in which people are killed and injured Any clause in the supplier contract restricting liability is null and void in this case

Information Systems p. 58/149

Unfair Contract Terms Act (2)


Death and personal injury are quite extreme cases (most software is not that critical) In other cases it has to be reasonable for a supplier to limit liability What is reasonable in a particular case depends on the circumstances Some disputes over reasonableness end up in court

Information Systems p. 59/149

Consumer Sales
In the case of consumer sales (in contrast to business-to-business sales) a consumer has additional protection Sale of Goods Act 1979 and Supply of Goods and Services Act 1982 may also apply (and cannot be excluded)

Information Systems p. 60/149

Consumer Sales (2)


Sale of Goods Act states that a good must be t for purpose It has never been established if software is a good General consensus: retail software or software sold under shrinkwrapped licenses are covered Tailor-made software, however, is not covered: Supply of Goods and Services Act applies This only requires that reasonable skill and care has been used, which can be difcult to disprove in court

Information Systems p. 61/149

You might also like