Contraception is a form of risk management – couples can choose from a host of different methods and procedures. None is 100% safe, and different methods suit different people. In a similar vein, risk management in the IT industry means different things to different people. Historically, contracts have been the main method used by suppliers to protect themselves against claims for breach of contract and negligence.
For decades, it has been an article of faith in the IT industry that suppliers can exclude consequential loss. Recent cases1 have blown a hole in that view. Up until 1996, many IT lawyers advised that software, being the result of services, need not be fit for purpose. We now know that contracts for the supply of software contain an implied term that it should be fit for its intended purpose.2 More recently, a court decided that a contract to supply software contained a range of implied terms.3 The Contracts (Rights of Third Parties) Act 1999 has also opened the door to third parties bringing claims against a supplier, where they have no direct contractual relationship with them.
As a result, the IT industry has started to pay close attention to other means of managing the risks associated with the relationship between supplier and customer. The new CSSA contract guidelines4 note: “. the contract is a natural part of the sales cycle, and is a key tool for managing risk – along with effective relationship management, business processes, project management, training and insurance.”
How process failings lead to disputes
Many of the cases in the industry have originated from failings in how companies do business, especially around the so-called Sales Cycle. Before we examine some of these cases, it is necessary to understand the jargon and the processes which suppliers follow when selling and delivering products and services to their customers.
People in the industry often use phrases such as ‘qualifying leads’, ‘sales cycle’, ‘sales pipeline’, ‘internal view’, etc. These are tell-tale signs that their company operates procedures (commonly called processes) for selling and delivering its products and services. In companies with only a few staff, these processes are often well known, but not necessarily reduced to writing:
- the MD must sign all contracts
- no fixed price software development projects
- Head of Projects to review all proposals.
As companies grow, it is no longer sufficient to rely on procedures which are passed on by word of mouth, or else they run the risk that individuals will become bottlenecks to doing business, or that new staff will be unfamiliar with company rules. At this stage, processes are likely to be codified and publicised. By the time they reach the maturity of IBM or EDS, the company will have well developed processes which the legal department or contract managers may be required to police (at this time, sales people may unkindly start to refer to them as ‘sales prevention officers’).
- A simple Sales Cycle involves the following steps, which might take weeks or months to complete:
- qualify opportunity – ie is this the type of customer that the company does business with, and is there a product or service that may meet its needs?
- establish prospect’s requirements – by reading ITT or RFP (Request for Proposals), attending meetings and/or running workshops
- submit proposal – this will detail the products or services to be supplied, the associated charges, and how and when those products or services will be delivered
- negotiate and finalise contract
- handover from sales team to delivery team – in practice, delivery people such as project managers may have been involved much earlier in the Sales Cycle.
The lack of involvement by delivery people in the Sales Cycle lies at the heart of many disputes (commonly called the Sales/Delivery gap). At worst, sales people may lie about the capabilities of the product being sold,5 or misrepresent key facts on which the purchaser relies in entering into a contract.6 In other cases, the supplier may underestimate the degree of effort involved in developing software,7 generally because they have failed to make the enquiries necessary to understand the functionality required by the customer. In the Marconi case, Marconi entered into a fixed price contract to supply a mobilising system to the London Fire Brigade. A fixed price of around £3 million covered the provision of hardware, software and services. An internal breakdown of Marconi’s price showed that it had budgeted £250,000 to cover software development that eventually cost more than £5 million.
One of the author’s favourite war stories involved a contract to design and build a card management system for a credit card business. The supplier estimated that the project could be completed in 12 months by a team of three people, ie 3 man years of effort. It quoted a fixed price based on that estimate. Thirty months into the project, the supplier had 40 people working full time on the project, and it was going to take at least 40 or 50 man years to complete. The customer terminated the contract, but went into liquidation before it could pursue a successful claim.
The moral from these cases is to involve delivery people early in the Sales Cycle, so that they can help to establish the customer’s requirements, and to validate any technical solution put forward in the proposal.
The role of management in minimising disputes
Management plays a crucial role in limiting risk. Management is either internal to the supplier (for example, sales management), or customer facing, such as account management or project management.
Companies should establish rules which make it clear who has authority to sign contracts, submit proposals, quote prices, and so on (authority limits). Typically, authority limits are communicated through a handbook or intranet. The rules should take account of the culture of the business and the markets in which it operates. Some businesses are run on entrepreneurial lines with lots of delegated authority, some are run by owner managers with a controlling zeal, and others are part of mature international operations with well established processes. Decisions based on the rules should be underpinned by an effective audit trail.
Rules can be reinforced through an internal training programme – many suppliers now run risk management courses as part of their induction process or career development programmes for managers. A typical course would cover business process, authority limits, standard contracts and some legal education (perhaps around recent case law), presented by veteran business managers and lawyers.
Before a customer signs a contract, they will already have a relationship with the supplier, created by a sales person or account manager. Account management could cover:
- discussing new requirements
- selling more products and services
- dealing with complaints about service delivery
- sorting out queries about invoices
- holding regular account meetings.
Good account management can often defuse difficult situations before they get out of control.
Over the course of several decades, the industry has developed tried and tested techniques for managing projects and developing software.8 These are commonly referred to as ‘methodologies’. By following methodologies, suppliers produce better quality products which are more likely to be delivered on time and within budget.
Poor project management has been a feature of a number of cases.9 In Salvage Association the judge found that Cap’s project team had little knowledge and experience of the chosen software development platform (ORACLE 5 RDBMS); the functional specification and system specification were defective; Cap had permitted the design and coding phases of the project to overlap significantly; the software delivered for acceptance testing had many bugs in it, and the system generally suffered from very poor response times. There is little excuse for failures like this given the availability of methodologies, project planning tools and project management training courses.
Although suppliers’ failings tend to be more newsworthy, there are plenty of examples where customers have failed to meet their responsibilities on a project – changing requirements, lack of resources and internal politics have all played their part in project failures.10 In the vast majority of reported cases, there has been little recognition by the courts that customers bear any responsibility for project failures. The recent Anglo Group case11 marks a more mature approach, with the court finding that in relation to a contract for the supply of a standard computer system the following implied terms apply:
- The customer communicates clearly any special needs to the supplier.
- The customer takes reasonable steps to ensure that the supplier understands those needs.
- The supplier communicates to the customer whether or not those precise needs can be met and if so how they can be met. If they cannot be met precisely, the appropriate options should be set out by the supplier.
- The supplier takes reasonable steps to ensure that the customer is trained in how to use the system.
- The customer devotes reasonable time and patience to understanding how to operate the system.
- The customer and supplier work together to resolve the problems which will almost certainly occur. This requires active co-operation from both parties. If such co-operation is not present, it is likely that the customer will not achieve the desired results from the system.
Insurance
Insurance should be seen as a safety net, not a first port of call. There is a choice of policies and insurance providers to cover the risk of professional negligence and breach of contract. A detailed examination of insurance lies outside the scope of this article, but it is worth making a few points.
Insurers may avoid picking up the bill for a dispute as a result of late notification of the claim by the insured (read the policy wording carefully, as the insured is generally expected to notify the insurer as soon as it becomes aware of circumstances that may give rise to a claim, and not just on receipt of a letter of complaint or claim document).
The insured also owes the insurer a duty of good faith – in practice, this means that material facts relating to its business should be disclosed (for example, a change of business direction, such as the launch of new products or services, or entry into new markets, such as the United States). Failure to do so will jeopardise cover.
Once the insurer accepts that a claim is on cover (in other words, that the insurer will take responsibility for it), the insurer stands in the shoes of the insured in relation to the claim. They decide which lawyers to instruct, how to conduct the case, and when to settle or fight. Their wishes may (and often do) run counter to the wishes of the insured, but this is the price one pays for the insurer picking up the risk.
Finally, it’s worth remembering that a well proven approach to risk management may reduce premiums.
Conclusion
Risk management is not a magic bullet; nor is it the sole responsibility of a single individual or function. Risk managers also need to be alive to differences in culture, products and services, and the markets in which companies operate, so that they can adopt techniques which work effectively for them. Remember, risk management, like contraception, does not eliminate risk completely. It is more a case of informed risk taking.
Endnotes
1. British Sugar PLC v NEI Power Projects Ltd [1998] ITCLR 125; Pegler Ltd v Wang (UK) Ltd (No. 1) [2001] ITCLR 617.
2. St Albans City and District Council v International Computers Ltd [1996] 4 All ER 481; Horace Holman Group Ltd v Sherwood International Group Ltd (2000) WL 491372.
3. Anglo Group Plc v Winther Browne & Co Ltd [2000] ITCLR 559.
4. CSSA is the Computing Services and Software Association, a trade association representing over 700 organisations in the IT industry, from the giants like IBM, ICL and EDS to much smaller companies.
5. DSL Group Limited v Unisys International Services Limited (unreported), 19 October 1994.
6. South West Water Services Ltd v International Computers Ltd [1999] ITCLR 439; McKenzie Patten v British Olivetti [1984] 1 WLR.
7. GEC-Marconi Limited v London Fire and Civil Defence Authority (unreported), 9 March 1992; Salvage Association v CAP Financial Services Ltd [1995] FSR 654; The Saxon Hawk Group plc v Source One Solutions Limited (unreported), June 1992.
8. DSDM, Prince 2, SSADM.
9. Salvage Association v CAP Financial Services Ltd [1995] FSR 654.
10. Crash, Ten Easy Ways to avoid a Computer Disaster, Tony Collins, Simon & Schuster, ISBN 0 684 81688 1.
11. Supra, n 3.
