Caveat emptor: St Albans DC vs ICL

Preface

After 6 years of argument and dispute, a team of officers at St. Albans District Council found themselves on July 12th 1994 at The Royal Courts of Justice in the Strand, London about to make a case against ICL. It would be another 2 years before the case was finally resolved in the Court of Appeal.

One of the larger of the 250 plus shire districts in England, St Albans DC is a medium sized local authority, serving a population of around 126,000. It has a gross revenue budget in 1996/97 of £24m and at the time of the dispute it had an IS/IT unit of some 13 staff serving a workforce of 440.

ICL (International Computers Ltd) is traditionally the largest supplier of IT equipment, software and services to the local government sector in the UK. It has a turnover of some £2.9bn and is now part of the Fujitsu corporation. It employs some 19,000 staff.

Executive summary

• This is the story of a legal case brought by St Albans DC against ICL in 1994. The case was won by St Albans DC and the verdict upheld by the Court of Appeal in 1996, although the damages were reduced.
• The reason for the case was a software error in the COMCIS package supplied by ICL to local authorities for operating the Community Charge brought in by the Conservative Government in 1990. The case centred around a clause in ICL’s contract limiting liability to £100,000.
• The courts agreed that this was an unreasonable clause and awarded damages to reflect the financial loss incurred by St Albans DC Damages of £1.3m were awarded, a figure reduced on appeal to £685,000.
• The purpose of the report is to draw out the many lessons to learn from the case which affect three different communities, those of the law, local government and Information Systems/Information Technology (IS/IT).
• Whilst the case does not set legal precedents, it has changed the climate of contract negotiation for purchase of IS/IT facilities. The report draws out some important general implications and then focuses on three legal questions which are analysed in the report:
  • Q1. Were the contract terms unfair?
  • Q2. Was the judge right to find the limitation clause unenforceable?
  • Q3. Is software goods?
• There are many lessons to learn from the case study. The two key players on the St Albans DC side have grouped these lessons for the different stakeholders in managing the IS/IT function. Checklists of good practice tips are provided to support each stakeholder.
• We supplement this analysis by some concluding remarks. Firstly, we look briefly at possible alternative strategies and discuss whether some years on things might have changed. Secondly, we summarise for IS/IT colleagues the some of the lessons from the case as follows:
  • Teamwork was critical to the outcome of the case
  • Documentation does matter
  • Determination to challenge accepted practices does pay off
  • It is vital to have a strong IS/IT client agent function
  • Integrity and professionalism gives credibility

Finally, we show how MAPIT advice helps to reduce the risks in dealing with such a case.

MAPIT – Management and provision of IT

MAPIT is a programme of research and advice sponsored by Socitm. It is a subscription service to which some 250 local authorities and other public sector organisations now subscribe. It identifies and promotes good IS/IT management practice in local government. It uses a practical model of IS/IT management set in a public sector context, a model which is based on first principles and which is coherent, flexible and durable.

Set up in 1993, MAPIT has produced a series of comprehensive and detailed guidance on all the major themes on IS/IT management linked to the critical issues of the day. The guides provide highly relevant advice, using extensive case study material and written by practitioners for practitioners.

MAPIT is designed to take IS/IT into the 21st century with an objective of being the prime source of advice on the management of IS/IT in local government. Through MAPIT we seek to:

• Form the basis of professional development for IS/IT management in local government.
• Encourage subscribers to be proactive and take the initiative wherever possible.
• Be progressive and take subscribers forward by advancing the application of IS/IT to meet the new challenges facing local government.
• Become a productive way of sharing best practice and avoiding re-inventing the wheel.

Background to the community charge

St Albans District Council is one of ten shire districts in Hertfordshire. Shire districts are responsible for a range of services including housing, planning control and development, economic development, museums, leisure and arts services, parks, refuse collection, administration of housing benefits and environmental health.

In 1990, county councils were responsible for police, fire, highways, education, libraries and social services. Prior to April 1990, funding for these services was collected by shire districts on behalf of themselves and counties by means of domestic and business rates levied respectively on residential and commercial properties. Following the Local Government Finance Act 1988 as amended, local taxes were divided into two:

• Non-domestic rates collected locally but fixed and distributed nationally (i.e. the National Non-Domestic Rates, or NNDR, system)
• Community Charge payable by:
  • Individuals aged 18 or over (personal)
  • Owners of property not their sole or main residence (standard)
  • Owners of short term accommodation, e.g. hotels (collective)

Shire districts were obliged to maintain a collection fund into which they must pay:

• Sums received from the national non-domestic rate (NNDR)
• Sums received from the Secretary of State by way of revenue support grant
• Receipts from the Community Charge

Main payments out of the collection fund included:

• Sums due to precepting authorities e.g. county council
• Cost of the authority’s own services
• Contributions to the national safety net

Each charging authority was responsible for preparing a register of persons liable to pay community charge. Students in full-time education were required to pay one fifth of the charge. Each charging authority was required to base its community charge for a financial year (April 1st to March 31st) on the relevant population as at the preceding December 1st. The relevant population figure comprises numbers of adult chargepayers, student chargepayers, standard and collective chargepayers. After December 8th 1989, the relevant population return for December 1st 1989 could not be altered.

The timetable

Stage 1: The problem leading to legal action

1988

• June: Invitation to Tender from St Albans DC
• October: Award of Contract to ICL

1989

• February: Installation of Initial Registration Software (IRS)
• November: Installation of Community Charge Information Software (COMCIS)

1990

• February: Discovery of discrepancy in COMCIS

Stage 2: The legal action

1991

• June: Writ and Statement of Claim
• August: Defence
• September: Reply and Request for Further and Better Particulars of Defence
• December: Further and Better Particulars of Defence

1992

• April: Plaintiff’s list of documents served
• June: Defendant’s list of documents served
• June: Discovery
• August:
  • Plaintiff’s interrogatories served
  • Summons for Directions served

1993

• January:
  • Admission by Defendant that prior to releases 2036 and/or 2040 software capable of producing error
  • Answers to interrogatories served
  • Hearing of Summons for Directions
  • Order for further Discovery
• April: Supplemental list of documents served by Defendant Discovery
• June:
  • Amended Admission − software capable of error prior to release 2040
  • Amended Defence
  • Exchange of witness statements
• October: Set down for trial

1994

• July: 10 day trial
• October: Judgment
• November: Notice of Appeal

1995

• May: Amended Notice of Appeal

1996

• June: 6 day Hearing before Court of Appeal
• July: Judgment by Court of Appeal

Section 1: Introduction

1.1. Purpose of report

This is the story of a legal case which is very well-known in three different communities, those of the law, local government and Information Systems/Information Technology (IS/IT). The story starts in the late 1980s with the implementation of a highly controversial piece of legislation, subsequently abandoned after just four years, and ends up in the Appeal Court eight years later.

Our intention in publishing the story is certainly not to take one major supplier to task. The courts have given their verdict. We intend to analyse the lessons to be learnt and believe that this case study has a wealth of material to share within the three communities affected. It is a story of a local authority which managed extremely professionally a difficult problem with severe financial consequences, against the odds. The purpose of the MAPIT programme is to identify and promote the best IS/IT management practice in local government and there is much to admire and learn from the way St Albans DC responded to the problem created by the software error.

We have selected this story as the subject of a special issue paper in the MAPIT programme because its lessons should be debated as the same communities are likely to cross paths more regularly in future over such matters. Similar problems are very likely to recur as organisations grapple with the Year 2000 software problem against a deadline which is even more immovable than Community Charge seemed in 1989/90.

Year 2000 compatibility, however, will not be the only source of conflict between IS/IT users, suppliers and their legal advisers. Managing IS/IT contracts is now a critical competency for organisations whose operations often depend totally on IS/IT being provided from a host of third parties, be they equipment manufacturers, software houses, service providers or consultants. Add to that an increasing trend for organisations to go to litigation and there are many good reasons for publishing this case study now.

1.2. Structure of the report

In order to learn the lessons we have to describe the story in some detail. We do this in section 2 as factually as we can, bearing in mind that the story is told from a local authority perspective. From this to draw out in section 3 an analysis of three major legal questions which are relevant to the IS/IT industry. Then in section 4 we examine the lessons to learn from a number of perspectives, including the IS/IT supplier perspective (as seen by the customer).

The body of the report (sections 2, 3 and 4) has been written by the two key players on the St Albans DC side, Martin Ferguson who is the Head of IT Services and Michael Lovelady who is the District Solicitor and Secretary. In section 5 we broaden the scope of the analysis by suggesting some concluding thoughts from fellow IS/IT professionals in local government who heard the story when it was told on a public platform. Finally, we relate some of those conclusions to advice already offered to subscribers to the MAPIT programme.

Section 2: The story

2.1. The invitation to tender (1988)

On July 28th 1988, the Local Government Finance Act 1988 gave statutory force to Community Charge a new system of local taxation which was to replace domestic rates. Under the new system all adult local residents (subject to a limited category of exemptions) would be liable to pay for local authority services.

All adults liable to pay the charge (commonly referred to as the poll tax) would be required to complete and return a registration form to their local council.

In June 1988, St Albans DC invited tenders from a select list for the supply of computer hardware and software to perform a number of functions including collection of housing rents, housing benefits administration and a registration, billing and recovery system for the community charge and non-domestic rates which was to be introduced on April 1st 1990. The Invitation to Tender included the following statement of user requirements.

“The Council invites tenders from a pre-selected list of suppliers for the provision of a computerised system for community charge and non-domestic rates. This is necessary to cope with the requirements of the Local Government Finance Bill currently proceeding through Parliament. As the Bill has not yet received the Royal Assent, and a large number of statutory Instruments / Regulations have still to be laid before Parliament, prospective suppliers will be expected to give a firm commitment to provide a system to cope with all the Statutory Requirements for registration, billing, collection and recovery and financial management of the Community Charge and Non-Domestic Rates; including Community Charge Rebates.”

2.2. The evaluation of tenders (1988)

In July 1988, tenders were received from five companies including ICL. In their response ICL indicated that they would supply COMCIS, described as a comprehensive solution for community charge being developed in conjunction with English Authorities. In answer to the council’s requirements for a computerised Community Charge Register, ICL responded as follows:

“The register will contain the data items necessary to meet at the very least the legal requirements plus any other fields the User Design Group deem advantageous. All other requirements will be met.“

The tenders were assessed by a team of St Albans officers from its Finance and IT departments with assistance from consultants Cooper and Lybrand. The team reduced the shortlist to two, ICL and IBM Lychgate. The respective merits of the short-listed tenders were summarised in a report to the council’s Policy and Resources Committee on 6 October 1988. The committee agreed to accept ICL’s tender of £1.3 million over 5 years and authorised the council’s officers to enter into contracts with ICL for the supply, implementation and maintenance of computer systems. The report envisaged that negotiations would be held with ICL to ensure the best possible deal for the authority.

2.3. The negotiation of the contract (1988)

19 October 1989

Mr Martin Ferguson, head of the council’s IT department made arrangements to meet with Mr Graham Tindall of ICL to discuss the contract terms. At this meeting Mr Tindall made plain to Mr Ferguson that ICL’s tender was based on its standard terms and conditions − their 1985 General Conditions of Contract for the supply of Equipment, Programs and Services. Clause 9 provided that ICL’s liability would be as follows:

• for negligently causing injury or death of any person liability would be unlimited.
• for negligently or otherwise being responsible for damage to or loss of any physical property liability would be limited to £250,000.
• in all other cases, ICL’s liability will not exceed the price or charge payable for the item of Equipment, Program or Services in respect of which the liability arises or £100,000 (whichever is the lesser) provided that in no event will ICL be liable for:
  • loss resulting from any defect, or deficiency which ICL shall have physically remedied at its own expense within a reasonable time; or
  • any indirect or consequential loss or loss of business, or profits sustained by the customer; or
  • loss which would have been avoided by the customer following ICL’s reasonable advice and instructions.

Mr Ferguson expressed his unhappiness with the £100,000 liability limit. Mr Tindall informed Mr Ferguson that the contract must be signed by noon on Monday October 24th. Otherwise, there was a risk that the partially installed computer hardware, which had been reserved for St Albans, might not be available.

20 October 1988

Mr Robin Brough of ICL wrote to Mr Ferguson. In his letter he confirmed that ICL’s offer was based on their standard terms and conditions and given the tight timescale advised Mr Ferguson to make use of them. He also pointed out that these standard ICL conditions were accepted by over 250 local authorities.

21 October 1988

A further meeting was arranged. This meeting was attended by Messrs Brough and Tindall for ICL and by Messrs Ferguson, Lovelady (the council’s in-house solicitor) and Williams (the council’s Purchasing Manager). ICL’s representatives reaffirmed that ICL traded only on their standard terms and conditions. If the council objected to the terms it would be necessary to refer the matter to ICL’s legal department. This would mean a delay and the delivery timetable for the computer could not be guaranteed. The council’s officers decided in the circumstances that they had little option but to accept the standard terms.

25 October 1988

A contract containing the Invitation to Tender, ICL’s response and the 1985 General Conditions was drawn up and sealed by the council. The computer hardware, a Series 39 Level 35 DXP mainframe model, was delivered a few weeks later in November.

23 December 1988

The contract was sealed by ICL.

In total, ICL contracted to supply COMCIS to 121 local authorities.

2.4. The initial registration (1989)

In February 1989, ICL supplied and installed Initial Registration Software (known as IRS) which was used by councils to create a database for the Community Charge Register. In July the council entered into a contract for the services of a part-time project manager, Mr Turton, provided for 2-3 days a week by ICL. His terms of reference placed responsibility on him ‘for the success of the IT project’ and ‘to co-ordinate Client, ICL and Third Party resources’ and ‘to plan for and minimise risk areas’. He chaired and minuted regular project review meetings involving staff from the council’s IT and finance departments.

During the summer and autumn of 1989, the council’s finance staff issued canvass forms and then entered the replies into the IRS software.

14 October 1989

A hard copy print out of numbers of persons on the register based on the IRS system was produced.

30 October 1989

ICL delivered and installed the main COMCIS software at St Albans. The information recorded on the IRS system was transferred to COMCIS.

2 November 1989

The Secretary of State for the Environment wrote to all charging authorities including St Albans DC, of his intention to require authorities to submit a return of relevant population on form CCR1 by no later than December 8th 1989. The relevant population figure was to be used for calculating the amount of community charge, the total precept due to the county council, the amount of revenue support grant payable from the government and the amount of contribution by St Albans DC to the safety net (an equalising mechanism intended to minimise the effect of the community charge between areas during the first few years of the charge).

3 November 1989

At a meeting of the St Albans project review it was confirmed that COMCIS had been fully installed.

4-5 November 1989

On this weekend a COMCIS accounts scan was run by the Council’s IT department in order to compare the information that had been carried over from IRS. Although the statistics were produced on the computer screen the hard copy printout produced zeros. The computer took 40 hours to carry out the scan and therefore this task had to be carried out over a weekend.

9 November 1989

ICL issued software release 2020 which was delivered and installed on the council’s computer.

15 November 1989

The Local Government Housing and Finance Act 1989 was enacted.

22 November 1989

Form CCR1 was sent to all charging authorities to complete. The form required information as to relevant population as at December 1st 1989.

29 November 1989

A project review meeting was held at St Albans DC. At this meeting Mr Turton was asked whether it was safe to take the figures for the DoE return from the screen (because the previous printout had produced zeros). Mr Turton confirmed that with the exception of students (which had to be calculated separately) the screen could be used for this purpose.

1 December 1989

ICL issued upgrading release 2036 to their local authority customers. Release 2036 was produced for the statistics to be provided to the Department of the Environment. For some reason, this software release was never delivered to St Albans DC.

2-3 December 1989

On this weekend the council’s IT department ran the COMCIS accounts scan.

4 December 1989

On this Monday morning, Mr Martin Marlborough, a Senior Income Assistant in the Council’s Finance department, took the statistics from screen CCE 59 for the purpose of the DoE return (the printout had continued to produce zeros). He compared the figures on the screen with the statistics from the IRS printout on October 24th. So far as Mr Marlborough was aware, the figures produced from the screen were reliable. Having added the figures for students, Mr Marlborough referred his calculations to his supervisor Mr Emery, who entered the figures on form CCR1.

4 December 1989

On this afternoon software release 2037 was delivered by ICL and installed by one of their staff, Mr Boyle.

5 December 1989

Mr John Collins the council’s Director of Finance signed form CCR1 showing a relevant population of 97,385 as at December 1st 1989. The form was sent to the DoE.

11 December 1989

ICL delivered software release 2040 which was a complete upgrade.

14 December 1989

This release was installed. It replaced previous software releases i.e. 2020 and 2037.

11 January 1990

The Secretary of State made and laid before Parliament the population report (England) which provides that the relevant population for each area is to be circulated in accordance with CCR1 return.

2.5. The setting of the Community Charge (1990)

During January and February 1990, precepts were received by St Albans Council and calculations were made of the relevant income and outgoings of the Collection Fund. In the light of these calculations and on the basis of a relevant population of 97,385, the appropriate level of community charge was provisionally assessed at £394.33 for year commencing on April 1st 1990. A council meeting was arranged for 28th February when the amount of Community Charge would be fixed.

9 February 1990

Mr. Emery carried out an accounts scan which shows a population of 94,757. Mr Emery queried this figure with Mr Thake, one of the two COMCIS ICL implementors assigned to St Albans DC. Mr.Thake assured Mr. Emery that the new figures must be wrong and that revised software shortly to be issued would correct the error.  A new software release was delivered and installed.

24-25 February 1990

A further accounts scan was run over this weekend, but when examined by Mr Emery, the statistics were comparable with the February 9th figures. Later that day, Mr Collins the Director of Finance was informed that the December figures may be untrustworthy. Following discussions with Mr Collins and the Leader of the council, the council’s Chief Executive, Mr. Hackford, decided it was far too late to change the proposed level of community charge as they could not be certain which figures were correct.

27 February 1990

Querymaster, (a report generator) was used following ICL’s guidance and produced a third set of figures.

28 February 1990

Following a telephone call and at ICL’s request, Mr. Ferguson wrote to ICL asking them to account for the discrepancy and querying which were the correct figures. Mr Hackford concluded it was impracticable to delay given the council’s timetable for printing bills in time for the new financial year on April 1st.

On this evening following disturbances in the Council Chamber from protesters against the principle of the charge the council agreed to set a personal Community Charge of £394.33 based on the relevant population return.

2.6. The error in COMCIS (1990)

Unknown to the council, the COMCIS software used by the council to take the figures from the screen (release 2020) was defective. The figures should have shown a relevant population of 94,419. The figures returned to the Department of the Environment had overstated the relevant population by 2,966. This error had disastrous financial consequences for St Albans DC. The council’s calculations in setting the community charge wrongly assumed that its chargepayer population was 97,385. There was a shortfall of Community Charge receipts amounting to £484,000. The council also had to pay a net increased precept to Hertfordshire County Council of £685,000. The council’s loss was £1.3 million. Chargepayers in 1991/92 had to pay an additional sum of £13 per head in order to make good the shortfall.

Attempts were made by the council’s Head of IT Mr. Ferguson, to determine the cause of the error. However, the source code for the software had not been retained by ICL.

In May 1990, Mr. Hackford, the council’s Chief Executive, wrote to ICL formally holding the company responsible. ICL denied liability and also drew the council’s attention to the clause in the contract limiting liability to £100,000. Joint attempts were made by ICL and St Albans DC to seek assistance from the Department of the Environment. However, they were unable to help.

The dispute was referred to the council’s in-house solicitor, Mr Lovelady, who after interviewing council officers involved, sought leading counsel’s advice in October 1990. Counsel, Mr Richard Mawrey QC, advised that on the evidence available it appeared that ICL had acted in breach of contract. He recommended that in the absence of satisfactory proposals from ICL legal proceedings should be commenced. A letter before action was sent to ICL’s in-house solicitor in April 1991. ICL continued to deny liability. Therefore, in June 1991 a High Court Writ and Statement of Claim was served seeking damages of £1.1 million plus interest.

2.7. The legal action (1994)

ICL decided to defend the action and instructed their solicitors to prepare a defence. They denied that they were in breach of contract. ICL admitted that COMCIS software prior to the issue of release 2040 was capable of producing the type of error experienced by the council. However, they contended that release 2040 was delivered to the council on December 4th 1989 in sufficient time to be installed and used for the DoE return. They alleged that the zeros on the scan print out should have alerted the council to the fact that there was a program malfunction. They maintained that the council failed to heed the contents of release notices 2037 and 2040 and also a fax dated December 6th 1989. ICL denied that the council had suffered any loss and also sought to rely inter alia on clause 9(c) which limited liability to £100,000.

The case was tried by Mr Justice Scott-Baker in a trial lasting 10 days during July 1994. When giving evidence, Mr Turton agreed that his job was liaison and that the council were entitled to assume that he had access to information about the reliability of the figures on the screen. He also agreed that no warning was given to the council between November 29th 1989 and December 8th 1989 that the screen figures were likely to be faulty.

2.8. The judgment (1994)

The judge was satisfied that release 2040 was not delivered in time for the DoE return. As to the argument that the zeros on the printout should have alerted the council to a program malfunction the judge considered that the officers did not have the expertise to appreciate this especially in the light of Turton’s assurance. The judge found that no categorical message was ever given to the council, as it should have been, that the figures on the TP screen were unreliable. He found that by the morning of December 4th the figures had already been taken to complete CCR1 and in practical terms it was therefore too late to seek another set. He concluded that, when lodging form CCR1 with the DoE, the council officers were entitled to believe that the figures were correct. The judge considered that when the council had set the community charge in February 1990 despite having suspicions about the CCR1 figures they took the only practical course open to them.

With regard to the contract the judge accepted submissions made by Mr Mawrey QC for St Albans DC that ICL were under an obligation to provide software that would maintain a reliable database of the names entered into the Community Charge Register, accurately count the names and accurately retrieve and display the figures resulting from the count. The software had to be reasonably fit for the purpose of maintaining and retrieving a reliable register. The judge said that ICL had manifestly failed to discharge this obligation.

2.9. The appeal (1996)

In June 1996 ICL appealed to the Court of Appeal. ICL maintained that they were under an obligation to supply a system which was fully operative by the end of February 1990 when the Community Charge had to be set. Their counsel, Mr Dehn QC, claimed that ICL were not contractually bound to provide software which would enable the correct figure to be extracted from the computer on December 4th 1989.This argument was rejected by the Court of Appeal. In the court’s view, the contract documents clearly contemplated that ICL would provide a computer system that met the statutory requirements even though many of these requirements were unknown when the contract was signed. Accordingly, once ICL became aware soon after November 2nd 1989 of the Secretary of State’s intention to require charging authorities to make a return of relevant population on form CCR1 no later than December 8th 1989, they were under a contractual obligation to supply the council with software to enable them to accurately complete the return by that date.

The Court of Appeal considered that the judge was right to find that ICL were in breach of contract. The installation of release 2037 on December 4th could not have put the council on notice that the figures already extracted might be wrong. The court also rejected arguments that the council was in any way at fault by not doing a re-run of the figures after the installation of release 2040 in December. Also, the council was entitled to rely on an assurance by Mr Thake that the figures produced by February 9th scan were incorrect. The court also rejected criticisms of the judge’s findings with regard to the council’s decision to set the Community Charge at their meeting on February 28th.

The court ruled that the council was entitled on behalf of its chargepayers to recover as damages the £685,000 in net additional precept paid out to the county council. Otherwise, the chargepayers would be out of pocket. The £484,000 in lost Community Charge receipts was on a different footing. If the software had not been faulty the Council would have collected this sum by way of an additional charge in 1990/91. The council was bound to recover this sum in 1991/92. The chargepayers were under an obligation to pay in 1991/92 precisely what they ought to have paid in the financial year 1990/91. Consequently, if ICL were required to pay this sum, the chargepayers would receive a bonus. Accordingly, the council was only entitled to interest on the £484,000 for the year 1991/92. Damages were therefore reduced by £484,000.

The council’s case in both the High Court and the Court of Appeal was prepared by its in-house solicitor, Mr Michael Lovelady. ICL were represented by two city firms, Kennedys in the High Court and Masons in the Court of Appeal. With interest and legal costs, the council finally recovered some £1.2m as a result of the proceedings.

Section 3: The legal analysis

3.1. What are the implications of the case?

The lay person is very interested to know whether this case sets a precedent. The simple answer is that it does and does not!

The first question in any case of this type is to ask whether ICL was in breach of contract for supplying defective software. Each case turns on the facts presented and every case is different. The court found that ICL was in breach. The next question is to ask what the implications are of this judgment.

It was an important case for a number of reasons. For example, it was the first legal challenge against a dominant supplier used to operating to its standard terms and conditions. However, in strict legal terms no precedent was set but it has certainly changed the climate of contract negotiation and management between customer and supplier in various ways:

• When determining IS/IT customer/supplier disputes, the courts will closely examine any promises made in the contract by the supplier as to the system’s performance.
• IS/IT suppliers will be held liable for assurances given by their staff as to the reliability of their software.
• IS/IT suppliers may no longer argue that, where the software is in the course of development, the customer must, in the absence of the supplier’s negligence, accept the software, bugs and all.
• When an IS/IT supplier expressly agrees in a contract to provide software which will meet a specified purpose by a set date, the supplier will be held liable if that software is not delivered on time and fit for its intended purpose.
• If the parties deal on a supplier’s standard written terms of business, then the Unfair Contract Terms Act 1977 will apply, notwithstanding any pre-contract negotiations.
• IS/IT suppliers to local government with substantial resources and product liability insurance may find that their exclusion/limitation clauses are unenforceable. Limits which bear little relation to potential or actual financial risks to the customer are unlikely to be upheld.
• Even where an IS/IT supply contract does not contain express terms as to quality or fitness, the courts may imply a term that the program must be reasonably capable of achieving its intended purpose.

These, then, are the main implications of the case, but there are three further specific legal issues which the case has thrown up, dealt with in sections 3.2 to 3.4 below.

3.2. Were the contract terms unfair?

One issue of vital importance in this case was whether or not ICL were entitled to rely upon Clause 9(c) of their General Conditions of Contract. Under Clause 9(c) ICL sought to limit their liability in the event of a claim for breach of contract to the price payable for the equipment, program or service or £100,000, whichever was the lesser. There was also a further limitation clause limiting liability to £10,000 in an application product development service agreement but this was held by the judge not to be relevant.

By means of the Unfair Contract Terms Act 1977, Parliament imposed restrictions on the ability of parties to contract seeking to rely upon exclusion or limitation clauses. By Section 3 of the Act a party, when in breach of contract, cannot rely upon a term excluding or restricting liability in respect of that breach, except insofar as the term satisfies the requirement of reasonableness. The Act applies in non-consumer contracts where one of the parties deals on the other’s written standard terms of business. Section 11 of the Act provides that the reasonableness test is determined by the question as to whether the term is fair and reasonable having regard to the circumstances which ought reasonably to have been known to, or in the contemplation of, the parties between whom the contract was made. In applying this reasonableness test the court may take into account a number of factors:

• In the case of clauses where an attempt is made to limit liability to a specified sum of money regard must be paid to the suppliers resources to meet potential liability and how far it was open to them to obtain insurance cover.
• The strength of the bargaining position of the parties, whether the customer received an inducement to agree to the term or in accepting it had an opportunity of entering into a similar contract with other persons without the term and whether the customer knew, or could reasonably have known, of the existence and extent of the term.

The onus of establishing that an exclusion or limitation clause satisfies the reasonableness test lies upon the supplier.

At the High Court ICL argued that the Act did not apply because negotiations had taken place between the parties and the contract incorporated a number of terms requested by both parties. This argument was rejected by the judge. He was satisfied that on the facts of the case that the council dealt on ICL’s written standard terms of business. He pointed out that ICL’s witnesses had expressly described their conditions as standard terms. The judge then went on to consider whether Clause 9 (c) satisfied the reasonableness test. The judge took into account the following factors:

• ICL were a very substantial company with ample resources to meet any liability. He noted that in November 1988, just after the contract with the council had been made, ICL issued a press release stating that they were a wholly owned subsidiary of the £2 billion STC Group which had achieved record results for the first half of 1988 with a profit before tax of £100 million.
• At the time of the contract ICL held product liability cover for £50 million world-wide.
• ICL were one of a limited number of suppliers who could meet the council’s requirements, all of whom dealt on similar standard conditions. Local authorities were governed by specific financial restraints, the need for public evaluation and often competitive tendering. The judge concluded that the council’s bargaining position, whilst stronger than an individual buying a car from a motor dealer, was weaker than that of ICL.
• The council had received no inducement to accept the limitation clauses and had had no opportunity of entering into a similar contract with another supplier without the clause. Indeed, the judge noted the evidence given by Mr Brough of ICL that all of ICL’s competitors operated with generally the same conditions.
• The judge found that the council knew about the term and had made representations about it.

The judge then carried out a balancing exercise in which he concluded that ICL had failed to demonstrate that their limitation clause was fair and reasonable. In his view, the determining factors were:

• The parties were of an unequal bargaining power:
  • ICL did not justify the figure of £100,000 which was small both in relation to the potential risk and the actual lossICL were insured
  • The practical consequences

Applying the final factor, the judge observed that in deciding on whom it was better that a loss of over £1 million should fall − a local authority or an international computer company − he observed that ICL were insured and in a position to pass on a premium cost to their customers. If the loss was to fall the other way, said the judge, it would ultimately be borne by the local population either by increased taxation or reduced services. In his view, he did not think it unreasonable that the company that stood to make a profit (ICL) should carry the risk. The judge said that the above factors outweighed the fact that computer companies and local authorities should be free to make their own bargains, that the council contracted with their eyes open, that limitations of this kind are commonplace in the computer industry and that COMCIS was an area of developing technology. He, therefore, disapplied the limitation clause and awarded the council damages of £1.3 million plus interest and costs.

3.3. Was the judge right to find the limitation clause unenforceable?

ICL challenged the judge’s approach to the Act. Mr Dehn, QC for ICL, submitted that you cannot deal on another’s standard terms of business if you negotiate with him over those terms. This argument was rejected. The court said that for one of the parties to a contract to deal on the other’s written standard terms of business it was only necessary for him to enter into the contract on that term. Deal meant “makes a deal”, irrespective of any negotiations which may have preceded it. On the facts the court agreed with the judge that St Albans had dealt on ICL’s standard written terms of business.

The Court of Appeal rejected arguments that the judge was wrong to prevent ICL from relying on the £100,000 limitation clause. An appellate court would not interfere with the judge’s decision on reasonableness, unless satisfied that he proceeded upon some erroneous principle or was plainly and obviously wrong. The Court of Appeal refused to interfere. Lord Justice Nourse commented that he would have given the same answer as the judge.

3.4. Is software goods?

The Court of Appeal also expressed an opinion on the vexed question as to whether computer software could be regarded as goods. If computer software is goods, then terms as to quality and fitness would be implied by statute into computer contracts. Any clause in a contract seeking to exclude the statutory implied terms will of course be subject to the reasonableness test under the Unfair Contract Terms Act 1977.

Lord Justice Glidewell said that, in order to answer this question, it was necessary to make a distinction between the program and the media carrying the program. Whilst a disk fell within the definition of goods, a program did not. Lord Justice Glidewell considered, however, if a disk with a defective program was sold or hired, then the disk including the program was goods to which the implied statutory terms would apply. In the case of St Albans DC the defective program 2020 was not sold or hired. ICL implementors went to the St Albans premises with a tape and directly transferred the program onto the computer. They retained the tape. Accordingly, no transfer of goods occurred. Nonetheless, Lord Justice Glidewell expressed the view that in the absence of any express term as to quality or fitness for purpose or any term to the contrary computer software contracts were subject to a common law implied term that the program was reasonably capable of achieving its intended purpose. Had the court not found that ICL were under an express contractual obligation to supply accurate software for the DoE return they would have been in breach of an implied common law term to the like effect.

Section 4: The lessons

4.1. The different stakeholders

This case has a number of important lessons for all those involved in managing the IS/IT function. In MAPIT we have identified partnership between the key stakeholders a critical factor in managing IS/IT. This is represented by the following diagram from Getting the Best from IS/IT (the MAPIT Impact Module):

From the local authority viewpoint this is an excellent example of partnership in practice. We can clearly relate the lessons to these stakeholders as follows:

• The user viewpoint as represented here by the Finance Department.
• The specialist viewpoint as represented here by the internal IS/IT client agent in the form of the IT Department.
• The executive viewpoint as represented here by the Legal Department advising the Chief Executive and elected members.

The remaining party is of course the external supplier and we believe that there are certainly lessons for the IS/IT industry to learn from the St. Albans case.

We summarise the lessons to be learnt from each perspective by way of checklist of good practice tips.

4.2. The user viewpoint

Definition of responsibilities

Generally, when embarking on any major IS/IT change project, such as the implementation of the Community Charge, the parties involved − including the users − need to define clearly at the outset what the respective responsibilities of each are to be, including communicating information about changes − new regulations, IT hardware and software problems and corrections, etc. In the St Albans DC vs ICL case, the main user was the Finance Department of the council. The user had the benefit of its knowledge and experience − the ‘intellectual capital’ of its staff. The way in which the department applied its knowledge, in this case of the local government revenues function and emerging legislative requirements, became a key feature of the case.

Relationships with the IS/IT specialists

The Finance Department was heavily involved with the council’s IT Client Unit and its chosen supplier − ICL − throughout the various stages of specification, procurement and implementation of the Community Charge system. The council had a clear view that it was the user department which was ‘in the driving seat’ by:

• Specifying the requirements for the Community Charge application set out in the council’s invitation to tender
• Attending the ICL COMCIS user design group, represented on the procurement team
• Undertaking the ‘canvass’ to draw up the register
• implementing the collection of the Community Charge

Managing the implementation

In order to achieve the controversial and ambitious central government timetable for this major change in local taxation, the various implementation tasks needed to be differentiated and delegated. The council entered into a contract for ICL to supply a project manager. In addition, ICL had in place a team of implementors who were responsible for administering the implementation of the emerging stream of COMCIS software releases. The judgment confirmed that it was the supplier who was responsible ultimately for delivering software which was fit for its purpose; this would include the necessity to update the user about all changes and developments of the software application.

Meeting the requirements

The purpose of COMCIS was set out in the user’s specification which was comprehensive, requiring the supplier to meet all of the forthcoming statutory requirements. As the judgment stated, the software would have to be fit for this stated purpose, even though the detailed regulations and their consequent requirements had yet to be determined. Such situations are not unusual. It is frequently the case that users are not in a position to specify precisely and a priori their requirements. It follows that users, as customers, need to think carefully about how they will specify requirements, including those that have yet to be determined, and where the risk of meeting such requirements should be borne.

Assessing the risks

A risk assessment should be carried out to identify what, potentially, could go wrong. Users should seek legal advice about the meaning and effect of any clauses put forward by the supplier which limit unduly or exclude liability. The supplier should be asked to explain the reasons behind such clauses. In some circumstances it may be appropriate to share risk with suppliers, for example where the requirements are emerging as part of a joint prototyping development. In the case of St Albans DC, the judgment made it clear that, for a number of reasons, it was appropriate that the risk and the associated liability to meet the statutory requirements set out in the emerging Community Charge regulations should fall on ICL. Once a specification has been formulated and the balance of risk has been agreed, users need to ensure that these matters are addressed explicitly in the contract documents.

Managing the project

During the implementation of COMCIS, the Finance Department took a number of measures, including:

• Holding regular progress review meetings with the ICL project manager.
• Raising queries with the ICL project manager and the ICL implementors.
• Ensuring that controlled procedures were in place, e.g. to process the incoming canvass forms.
• Obtaining clear direction in advance from the ICL project manager about the suitability of the figures produced by COMCIS to be used in the CCR1 return to the Department of Environment.
• Ensuring that the relevant figures were obtained and checked by more than one officer.
• Maintaining full written records, including minutes of meetings and records of conversations with ICL’s implementors, throughout the implementation of COMCIS.

The speed with which central government was introducing the Community Charge regulations meant that there was an extra challenge for suppliers of community charge applications to ensure that the software was fit for its purpose at any given time. St Albans DC expected this to be the case. It was understood that testing of all new COMCIS software releases would be undertaken by ICL at its trial sites prior to a general issue to its customer base. Indeed, users should require suppliers to test software prior to distribution, particularly where updating and error correction releases are concerned; this requirement should be covered in the contract.

Planning for contingencies

Ideally, users should maintain a fallback position, in the event that new technology, including software, might fail. Whilst this might be good practice, the judgment recognised that for a new function such as the Community Charge, such an approach would have been unreasonable. Here, St Albans DC had contracted ICL to supply software for the purposes of maintaining and reporting on a database, and of collecting the Community Charge. The user should have been able to rely upon the software to report correctly on the contents of the database. The figures produced by COMCIS in early December 1989 were consistent with those obtained in October 1989 from the Initial Registration System − an earlier version of the software supplied by ICL. The judgment confirmed that it was unreasonable to expect the user to perform a manual count of all 50,000 canvass forms, including the circumstances for exceptions, when it had purchased a computer system to perform the task, and anyway had no reason, at the time, to suspect that the figures were wrong.

Checklist of points for IS/IT users

• Make sure you are involved throughout the various stages of any major change project − in producing the specification, tender evaluation and selection, and implementation.
• Build on your strengths − particularly your knowledge and intellectual capital − to determine requirements.
• If the requirements have yet to be defined, then say so, and devise a form of words which makes it clear where the risk lies in the event of the system being unfit.
• Document all contacts made internally and with suppliers throughout the specification, tender, evaluation, selection, contract negotiation and implementation stages.
• Make sure that the specification is included in the contract.
• Carry out a risk assessment to determine what could go wrong, the potential impact of failures and what will happen if anything does go wrong.
• Determine what is a reasonable level of risk and limitation of liability for each contracting party to bear, and challenge the contract terms if they provide inadequate protection.
• Maintain management control of the project with clear identification of responsibilities, checks and balances.
• Make clear the respective roles and responsibilities, including communication, of all the parties involved in the project.
• Ensure tight operational procedures are in place for key functions (e.g. where the risk of failure for your organisation would be ‘critical’).
• Require the supplier to test all software prior to delivery; whenever possible, check software in a test system prior to live implementation.
• If possible, maintain a fallback position, so that, if problems occur after the technology is adopted, steps can be taken to reverse the impact.

4.3. The IS/IT specialist viewpoint

Context of an appropriate IS/IT strategy

The council’s procurement of its Community Charge system was not undertaken in isolation. It formed part of a coherent IS/IT strategy which gave the council’s management clear direction for its major financial systems and set out responsibilities, including those of users and the need for a central IS/IT support function.

By the late 1980s, most medium to large sized organisations had established a central IS/IT support operation with responsibilities which included IS/IT strategy, and commissioning and operation of IS/IT services. During 1987/88, St Albans DC undertook a major review of its IS/IT strategy, including its needs for major financial systems. Independent consultants, Coopers and Lybrand, were engaged by the council to assist with and advise on the development of an IS/IT strategy. Accepted by the council early in 1988, that strategy determined a need for the council to establish its own computer-based major financial systems and to set up a central IS/IT support function. Systems would be procured and implemented based upon application software packages.

The council had a clear goal to establish an IS/IT support function responsible for the IS/IT strategy and the support of operational IS/IT systems. The council took advice from its consultants over staffing structure and job descriptions. IS/IT management and technical staff with relevant knowledge and experience were appointed to ensure a good person-job fit, with Coopers and Lybrand again involved, this time in the recruitment processes for key posts. Equally, ongoing training of staff, including appropriate ICL courses, was undertaken to accumulate skills and knowledge necessary to manage and operate the council’s new mainframe computer operation.

Need for external assistance

It was recognised that, during implementation of the major systems, the IS/IT unit would need to be augmented by project management and implementation resources, both technical and user-oriented. ICL offered operational implementation services in the form of a team of contracted implementors shared across its COMCIS customer base. St Albans DC also took ICL project management services to manage the implementation of COMCIS. This would free St Albans DC staff to oversee the management of the strategy and to concentrate on the implementation and operation of the mainframe computer environment.

Value of teamwork

The central IT Unit coordinated a team of prospective users to produce a specification for the council’s major systems, including Community Charge. Independent advice was provided by Coopers and Lybrand to ensure that the specification was robust. The same consultants continued to be involved through the evaluation of the tenders and in scoring the relative merits of the contract terms and conditions offered by different tenders. The IT Unit managed the evaluation of the tenders (again, users were heavily involved); obtained approval from the council’s Policy and Resources Committee; undertook contract negotiations; and took overall management control of the implementation. Full notes and records of all meetings and discussions were maintained and filed.

The legal department’s assistance was sought at every stage of the procurement and tender process. Legal advice was sought about proposed contract terms and conditions and the form of the contract, and a solicitor was involved in the final contract negotiations with ICL.

The judgment recognised the inclusive nature of the specification (involving the user department and specifying the full statutory requirements of Community Charge, including the majority of the detailed requirements which would emerge in regulations); the thorough process by which tenders were evaluated; the fact that the Head of IT had expressly challenged the supplier’s limitation of liability clause during the contract negotiations; the form of contract that the IS/IT client had established; and the respective roles and responsibilities that had been contractually agreed by the parties for the implementation of systems. Care had been taken in forming the contract to ensure that all relevant documents were included and that all aspects of implementation outside the council’s directly controlled resources were defined and appropriately resourced.

Pressures of work

Although the council had taken appropriate advice in framing its specification, in selecting the preferred supplier and ensuring that the project was properly resourced, nevertheless, two difficulties emerged during the latter part of 1989 which conspired to put these arrangements under stress. One was the frequency of ICL’s software releases for the Community Charge, reflecting the frequently changing legislation. The other difficulty was the performance of the mainframe itself, particularly the speed of running ‘batch’ work. In order for the council’s developing IS/IT service to cope with the frequency of software releases and the poor performance of the mainframe itself, ICL’s implementation service agreed to install releases on behalf of the council. From the council’s perspective, this was a reasonable response to a peak of activity during the implementation of Community Charge and ICL’s response was a helpful one in the circumstances.

Need for accuracy

The Central Government imposed timetable for Community Charge was extremely tight and had been severely criticised by the Local Government Associations and others. Nevertheless, ICL had undertaken to meet all the statutory requirements of the Community Charge. The judgment confirmed that in this instance, the IS/IT client had a right to expect ICL’s software to be fit for its stated purpose. So it was that the appropriate suite of COMCIS programs was run in early December 1989 to produce the statistics needed by the user department to complete its return to the Department of Environment. As the judgment stated:

“‘The account scan that was necessary to obtain the figures for the CCR1 took about 40 hours to run. During that time, the computer could not be used for other purposes. Some foresight was therefore necessary in arranging the timing so as to accommodate other users. The obvious time to do the job was over a weekend. This was what was done. The scan was run over the weekend of the 2-3 December 1989, so that the figures would be ready for the deadline of Friday 8 December.”

There was no reason to double-check the statistics produced by the account scans and displayed on screen. Only a few days earlier, on November 29th, the ICL project manager had assured the council’s user and IT department representatives in a minuted project review meeting that the figures would be suitable to use for this purpose. In the words of the judgment:

“Turton [the ICL Project Manager] agreed that his job was liaison, and that the Plaintiffs [St Albans DC] were entitled to assume he had access to information about the reliability of the figures on the screen. He also agreed, that no warning was given to the Plaintiffs between 29 November and 8 December that the screen figures were likely to be faulty, and that they should have been given that information. The evidence reveals, in my judgement, some lack of communication on the part of the Defendants [ICL].”

The user department became suspicious about the validity of the statistics in early February 1990 − the next time that the relevant suite of programs was run, but received an assurance from the ICL implementor that the statistics would be corrected at the next release. When the next release produced yet another set of results, the user requested the IT Unit to run a separate, special report under the direction of ICL’s COMCIS help desk using a mainframe report generator. This done, a further set of statistics resulted. Immediately, these were queried by the council’s IT Unit with ICL − by telephone and in writing. Meanwhile, the council had no choice but to set the Community Charge in order to issue bills, to notify direct debit payers and to commence collection on 1 April 1990. In the judgment, Mr. Justice Scott Baker accepted that St Albans DC had no choice but to proceed with ‘the only practical course open to them’, in the absence of any definitive information from ICL.

Value of documentation

The fact that the IS/IT Unit had maintained accurate records throughout every stage of the project was to prove invaluable when the case came to court. As a result, the council’s IS/IT witnesses were in a position to satisfy the judge as to the delivery dates of software releases and that one release had not been delivered at all. It is critically important that IS/IT organisations should retain complete records of all change activity on IS/IT projects.

Once the decision had been taken by the council to pursue litigation in the High Court, a number of important steps were put into effect. All of the key people involved were identified, many of whom had been part of the team developing the specification and evaluating supplier’s tenders. This laid the foundation for the teamwork that proved vital in preparing the case for the court. Witness statements were taken immediately. Relevant files and documentation were assembled and preserved. Later in the process, all members of the ‘team’ commented on ICL’s witness statements and other issues as they arose. The result of this teamwork was a coherence in approach and a confidence that the relevant groundwork had been done.

4.4. The executive viewpoint (as advised by in-house solicitor)

Getting the right contract

Local authorities should comprehensively specify the objectives which the computer system will be expected to meet. Even where the market has already developed a software package to meet specified local authority functions such as housing benefit administration, council tax collection or electoral registration it is essential to ask prospective suppliers to confirm in writing that the system will meet the local authority’s needs. The supplier should also confirm that the software is year 2000 compatible. The specification and the supplier’s replies should be included in the contract. Delivery dates should also be clearly stated. The terms and conditions on which the supplier will provide the product is likely to prove the most contentious issue. The supplier will usually insist that the customer signs a contract incorporating a closely printed set of conditions. It is vital that these conditions are referred to the authority’s legal department for advice as to their meaning and effect. Clauses which seek to exclude or limit liability should be closely examined. The customer should carefully consider the implications for its services if the computer software proves to be defective. What consequences might follow? What financial risks are involved? These consequences should be drawn to the supplier’s attention.

Avoiding unreasonable terms

The St Albans DC vs. ICL case has undoubtedly changed the balance between customers and suppliers. After carrying out the steps suggested above the customer should write to the supplier drawing attention to the provisions of the Unfair Contract Terms Act 1977 and stating that in their view the clauses are unreasonable and unenforceable. Following the St Albans DC case it is now unlikely that courts will uphold a limitation cap that applies equally to all customers irrespective of contract value without applying the test of reasonableness. When applying the reasonableness test, courts will also have regard to the special position of local authorities e.g. their fiduciary obligations, their inability to insure against commercial risks and that they are non-profit making bodies and the practical consequences if losses have to be apportioned between customer and supplier in accordance with a limitation clause.

Keeping the documentation

After the contract has been signed, it is essential to keep copies of correspondence. Minutes should be kept of all meetings with the supplier’s representatives. Notes should also be made of telephone conversations. Where the supplier delivers a software release, a note should be kept of the date of delivery and installation. If a project manager is appointed, the terms of reference should include liaison between the supplier and customer and ensuring that the customer is kept informed of all problems and the steps taken to solve them. Customers should request the retention of source codes for software releases in writing.

Responding to faults

If the software does not perform satisfactorily and a major fault occurs customers should initially approach their supplier. The cause of the fault should be identified and, where the software has failed to meet the specification, the customer should write to the supplier seeking an admission of liability and confirmation they will redress the defect and pay appropriate compensation. Wherever possible, disputes should be resolved by negotiations between the parties. The customer should also approach other customers of the supplier to determine if the fault has been repeated elsewhere. If the supplier denies liability or seeks to reply on exclusion/limitation clauses in the contract, the customer should refer the dispute to their legal department without delay.

Checklist of legal points on IS/IT procurements

Contract negotiations

• Ask the supplier whether the clauses proffered are their standard written terms of business. The Unfair Contract Terms Act will apply if the customer deals on the supplier’s standard written terms of business.
• Make enquiries of the supplier’s resources. Obtain details of the supplier’s turnover and profit, e.g. by means of a company search.
• Ask the supplier whether they hold product liability insurance cover and the amount of cover. Ask to see a copy of the policy and the amount of the excess.
• Ask the supplier for the names and addresses of their current customers. Ask whether the limitation/exclusion clauses have been applied to all their customers.
• Invite tenders/quotations from a number of suppliers. In each case obtain copies of their conditions of business. Compare the terms.
• Object to any limitation/exclusion clauses, particularly where the supplier carries insurance. Ask the supplier the reason why they are seeking to include limitation/exclusion clauses when they are already insured and/or have substantial resources.
• Keep records of all meetings/telephone conversations with suppliers. Correspondence should also be retained. Documentary evidence may prove very useful in the event of a dispute.
• Ensure as far as possible that the specification, invitation to tender and supplier’s responses are included in the contract.

Post-contract

• Retain copies of correspondence.
• Make and retain notes of all meetings and telephone conversations with supplier’s representatives.
• Keep a record of dates of delivery of software releases and their installation on the system.
• Ask the supplier to retain source codes for software releases.

Disputes

If a problem arises with the performance of the software:

• Draw the issue to the supplier’s attention straightaway and seek an explanation as to the cause.
• Keep a record of the supplier’s response.
• Seek to negotiate with the supplier in an effort to achieve a solution acceptable to both parties − litigation can be costly and time-consuming.
• Consult with other customers of the supplier to determine if the problem has occurred elsewhere.
• Do not assume that contract terms and conditions will exclude or limit your claim.
• Seek legal advice at an early stage.

4.5. Viewpoint of IS/IT supplier

The High Court case focused on two key areas − the making of the contract and the occurrence of the software fault. A number of issues arise for suppliers from both of these situations.

Negotiating the contract

Sufficient time must be allowed for contract negotiations and for detailed terms and conditions to be agreed. As the High Court judgment stated:

“If the Plaintiff [St Albans DC] objected [to the use of ICL’s standard terms and conditions], the matter would have to be raised with the Defendants’ [ICL’s] legal department. This would mean delay and they would not, in the circumstances, be able to guarantee meeting the necessary timetable. The Plaintiffs immediate concern was that they would lose the reserved hardware. I am satisfied that the Defendants fully exploited this concern to obtain prompt agreement on the Plaintiffs part. The Plaintiffs had no realistic option other than to accept the Defendants’ terms”

So it was that the council had little choice but to accept the standard terms and conditions (and specifically the limitation of liability clause) or lose its place in the queue for an ICL mainframe coming off the production line and jeopardise its ability to comply with the statutory deadline for introducing the Community Charge.

During the course of the contract negotiations, ICL made no attempt to justify the level of limitation of liability which was set at £100,000 in its standard terms and conditions. No attempt was made to set a level of limitation in relation to the size of the contract (£1.3m), or to the availability of product liability insurance cover, or to the circumstances of St Albans DC. Further, it became clear during the course of the High Court case that ICL had offered its 1985 standard terms and conditions which had already been replaced by 1988 conditions with a higher level of limitation of liability of £125,000. The lessons are clear − suppliers will need to be much more circumspect about imposing standard clauses limiting their liability.

They will need to take account of the circumstances of each individual contract and customer before determining what would be considered a ‘reasonable’ limit.

Dealing with software errors

The issue of whether software can ever be entirely error free arose during the case. The St Albans DC-ICL contract stipulated that ICL would deliver software which was capable of producing an accurate return of persons liable to pay the Community Charge. A software error in the region of 3.1% resulted in a financial loss to the council of over £1 million. Both parties to a contract need to consider the potential consequences of any error. The authors agree with the views expressed by Mr. Justice Scott-Baker that he who stands to make the profit should carry the risk. In any event, the contract should contain clear procedures for resolving and correcting errors once they are discovered.

Finally, the form of contract must be agreed and, where a contract includes a bundle of relevant documents, it must be made clear which documents take priority.

ICL admitted fault ‘that the COMCIS package operating the Plaintiff ’s [St Albans DC] system was capable of producing the type of statistical error alleged’ before the case came to the High Court. Following examination of ICL’s witnesses in court, it became clear that key member of ICL’s staff had failed to communicate important information to the customer. Project managers need to be adequately trained and supervised. They must be fully integrated into the supplier’s internal communication channels. In the case of St Albans DC, the project manager gave a clear assurance (minuted by himself at a project review meeting) to St Albans DC officers to go ahead and prepare the statistics for the CCR1 return based on the current status of the COMCIS software. The situation was further complicated by the peripatetic presence of two implementors − ICL contract staff − to support implementation of COMCIS at a number of customer sites. Suppliers should take care over use of contractors in key front-line roles and ensure that communication channels are open and used effectively. They should be clear about their roles, the help to be given by their front-line staff and the need to keep them fully informed of progress and problems.

Communicating with the customer

Communication between supplier and customer is of critical importance in any software implementation project. ICL had established channels − a communiqué‚ newsletter and the User Design Review Group to communicate with its customer base. Customers need clarity over which channels are to be used for specific purposes, such as communicating:

• The current functionality and status of software
• Known errors
• Plans for error correction
• What each software release is designed to achieve

User information about each software release should refer to preceding and forthcoming releases. Suppliers should not rely on technical documentation aimed at computer and IS/IT staff to communicate user information about software functionality, nor should they rely on word of mouth.

Managing software releases

The issue and sequence of COMCIS software releases came under scrutiny in the case. It became apparent that ICL did not have a comprehensive record of which customers had received particular software releases, on what dates and by what means of carriage (courier, post or hand delivery by an implementor). It follows that suppliers should keep a full record of all software releases issued to customers, including the method of delivery.

Suppliers also need to maintain a clear record of what each software release is designed to do and ensure that critical releases are implemented properly at all relevant customer sites. At the ‘discovery’ stage, St Albans DC requested access to the source code for a number of COMCIS software releases. ICL’s response was that the source codes were not available. Suppliers should retain a copy of the application source code at each release state and a copy of the source code for each software release.

All this is no substitute for comprehensive and accurate testing.

Section 5: Some conclusions

5.1. Alternative strategies

This story has been told on a public platform by Martin Ferguson, Head of IT Services, one of the key players on the St Albans DC side. The words in this document are his words and those of his legal colleague, Michael Lovelady, District Solicitor and Secretary.

What we have presented here is the story as told by the local authority side and, whilst care has been taken to present it in as objective and balanced a way as possible, we have to accept that it might look differently when seen from a supplier’s perspective. No doubt, too, ICL and other suppliers have learnt from this experience and would handle the issues differently.

The case as presented here is a straightforward progression of a contract which leads to a dispute which, when unresolved, leads to a legal case. This is what happened at St Albans DC. However, some reflection does prompt other questions, not dealt with in the narrative:

• Were other avenues for resolving the case explored?
• Could the DoE have helped by being more flexible about the Community Charge rules?
• Could the county council, or other district councils, have helped to resolve the issue by adjusting the precept?
• What risks of incurring legal costs did St Albans DC take if it had lost the case?

There is not space here to discuss detailed answers to this kind of ‘what if’ questions. Suffice it to say that other options were explored (e.g. the DoE were approached but, whilst sympathetic, were not able to defray the cost elsewhere). St Albans DC did assess the risks of losing the case. Had the case been lost, the legal costs might have been in the region of £200k and £400k.

It is not the business of this report to question the way in which the local authority pursued its case. It judged the situation according to the circumstances of the time, taking the advice which was available. It is much more useful to ask if the circumstances arose again now how might a local authority react. The Community Charge was a highly unpopular piece of legislation enacted under great time pressures when arguably the relationships between local government and the private sector were on a collision course. But now the climate has changed. Concepts of partnership and joint working are the new flavour. Who knows what might happen now? There is every chance that Year 2000 software problems will test this out.

Some things have changed for the better. There is much more relevant advice around to help local authorities reduce the risks from this type of contract dispute. This is exemplified by the Buy IT guidance available from the Chartered Institute of Purchasing and Supplies (CIPS) which has been developed by a cross-industry group representing customers and suppliers. Specialist services such as those provided by Croners helps IS/IT managers through the legal minefield of IS/IT contracts. Model agreements are available from the CCTA and others. We also have our own MAPIT library to help IS/IT managers and their colleagues. (Don’t forget to use the Socitm website which has advice and points to many other sources of information, and also the Year 2000 website.)

5.2. Learning points for IS/IT professionals

Whilst of some interest, discussion about alternative strategies now is ultimately conjecture from the benefit of hindsight. It is much more useful to identify what can be learnt from this case for those involved in managing IS/IT in a local authority. This is not just an interesting story of what happened in the past.

There are a number of lessons which can be learnt for the future, especially, as our subtitle indicates, for those who may have to deal with a messy aftermath of Year 2000 software problems, or indeed are already in quasi-legal discussions over them. St Albans DC have already supplied their views of those lessons.

Those local authority colleagues who heard the story for the first time on June 12th 1997 would like to reinforce some of those lessons and perhaps add to them. We suggest that there are five such learning points in addition to the many more detailed points of advice offered by those who lived through the experience.

Teamwork was critical to the outcome of the case

We have already suggested in our introduction to section 4 that this is an excellent example of all the different stakeholders working in partnership. Whilst no local authority would ever wish to be involved in such a protracted case, the strong teamwork shines throughout the case. No doubt this was strengthened in the later stages of the case as positions hardened. This was symbolised in court itself as all the main participants from St Albans DC listened to the whole case from start to finish.

However, the teamwork developed right from the start of the project in 1988 when invitations to tender were issued. What stands out clearly from the case in the early stages is a clear understanding of roles and responsibilities.

Documentation does matter

This story covers eight years. The legal dispute took six years to resolve and the legal case was not even heard in court until year four of that dispute. This makes it essential that there are proper records to support the case. When there is the pressure of meeting deadlines, and the Community Charge saga imposed plenty of pressure on all concerned, it is easy to lose the discipline of updating documentation. It is very easy to lose track of what happened with new software releases appearing every few days over the critical period in November 1989. Who said what to whom in formal and informal meetings turns out to be of material evidence. IS/IT professionals have always extolled the virtues of such documentation and perhaps not always practiced them. Here is a classic case of benefiting from practicing what we preach.

One additional point about this which we have already seen in section 4 but is worth repeating is the need to take statements from all participants as soon as it is clear that there is a legal case to take to court. St Albans DC did this immediately. It was about three years from that point before the case was heard and the value of such prompt action is obvious.

Determination to challenge accepted practices does pay off

The essence of the story is the refusal to accept what has developed as custom and practice. Standard terms and conditions have been used by suppliers in dominant positions without challenge. How many heads of IS/IT have actually asked questions about limited liability? With remarkable foresight, one did in this case, even setting up a special meeting to follow up the point. When the issue came to court, no evidence was actually presented to support the reasonableness of the clause limiting liability.

This determination to take the challenge all the way into the courts contrasts with the five other local authorities who found themselves in the same boat with ICL but backed off from pursuing the case.

Persistence paid off. Future negotiations with suppliers of IS/IT services can now be seen in a different light.

It is vital to have a strong IS/IT client agent function

St Albans DC has outsourced some of its IS/IT services but has not made the same mistakes in dismantling the IS/IT function which others have made in following the outsourcing route. The case just could not have proceeded without a strong IS/IT client agent advising the authority. The professionalism of the IS/IT function is seen in every step of the process, for example:

• The setting up of the project team
• The adherence to a disciplined evaluation process
• The approach to contract negotiation
• The thoroughness of the record-keeping

Integrity and professionalism gives credibility

When disputes come to court, the credibility of witnesses is paramount. Opposing barristers will always try to discredit the witnesses. In this case the integrity and professionalism of the St Albans DC witnesses were clearly demonstrated when giving their evidence to the court. From just an IS/IT perspective, colleagues in other local authorities can see a valuable role model here. IS/IT units are occasionally seen by local authority users as laws to themselves, more interested in the technology than the business they serve. Most certainly this does not apply here. The case shows the level of professional skills demanded of IS/IT managers in local government, together with the determination required, as public servants, to achieve maximum value for money. The court case also highlights the need for strong communication skills from the IS/IT specialists. The Head of IS/IT at St Albans DC found himself in the witness box for 1.5 days!

These, then, are some of the main messages which can be drawn out from the case to supplement those already made by the participants on the local authority side. It is a very rich case study to analyse and space does not permit exploring many of the more detailed points such as the reliability of sub-contractors in supporting a court case, the observation by an ICL witness that no computer software is error free and the role played by those who insure suppliers against risks of this kind.

5.3. A MAPIT perspective

We would like to round off these concluding remarks by relating the case to MAPIT. Subscribers will be very used to reading about case studies provided by practitioners to illuminate the theory of sound IS/IT management practice. In this paper we have devoted a whole special issue paper to one case study because we believe it has many lessons for the future.

Subscribers have recently received in a joint report with Solace copies of The Information Society: Are You Ready? which picks out from the MAPIT library ten commandments in managing IS/IT. We see in the St. Albans DC vs ICL case the strongest evidence of the validity of some of those commandments. We can pick out just three:

• 1st: There must be a real partnership between all those who manage, use and develop IS/IT
• 7th: The clients for IS/IT services must buy wisely
• 9th: The risks associated with IS/IT must be properly managed

More specifically, we can point to key sections of individual MAPIT modules. For example, the Directory of IS/IT Services (Service Module) emphasises the need for clarity of responsibilities between client and contractor. The case illustrates how and why this matters. Another example is the section in IS/IT − Organising for Change (Structure Module) which stresses the importance of the IS/IT client agent function. We have already commented on the relevance of this. Thirdly, we identify and describe in The Good Skills Guide for Successful IS/IT (Skills Module), two of the critical skills in managing the IS/IT function as contract management and risk management. Finally, and perhaps the most important point of all is the concept of successful partnership between those who have a stake in the IS/IT function which is a key message from Getting the Best out of IS/IT (Impact Module).

Use of case studies is always a two-way process in MAPIT and there are points which we must build upon in the future and which we have not perhaps stressed enough such as:

• The way in which we should manage risks in major IS/IT initiatives
• The importance of certain skills required from IS/IT managers who might be required to pursue more cases through the legal process

We will doubtless return to the St Albans DC vs ICL case.