The Negotiation Competition, now in its fifth year, is a contest open to all law students in England and Wales, designed to promote the skill of negotiation, a crucial component of ADR (see further: www.Negotiation-Competition.co.uk). The 2001 Competition was sponsored by CEDR, Hammond Suddards Edge, the College of Law and CASTELL Consulting, and was won by BVC students from the Inns of Court School of Law (who then went on to win the International Negotiation Competition in California in July!).
Professor Karl Mackie, Barrister, Chief Executive CEDR, writing in The Barrister (Easter Term Issue 2001), and quoting Laurence Kershen QC, said "barristers are very adaptable... able to take on new behaviours very quickly". This year's Negotiation Competition winning team of young trainee barristers certainly had their adaptability tested and sharpened in grappling with a difficult negotiation scenario in the Final of the Competition - a failed software implementation project, in which a report from an independent IT Expert also figured.
I had the privilege and enjoyment of being one of the judges for that Final, and I was impressed by how quickly these talented students appreciated that disputes over real failed software construction projects raise complex interlinked technical and legal issues - whatever the financial size of the claims and counterclaims, the facts and circumstances of the contract, or the conduct of the software development.
Software development contracts, and software package "customisations" or "implementations", are frequently terminated with the software rejected amidst allegations from both supplier and customer. These include: incomplete/inadequate delivery, software/database errors, faulty design, operational/performance/response-time deficiencies, usability problems, shifting user/business requirement specifications, lack of co-operation, poor project management, delays and cost over-runs. For a case of significant size, an experienced IT Expert is usually appointed by each party (for smaller cases, increasingly a Single Joint Expert) to give opinion on these challenging and interwoven technical issues. Over the past 15 years, I have been involved as IT Expert in some 100 such cases, whether for Claimants or Defendants; systems/software customers or suppliers; in the High Court, or in Arbitration, Mediation, and other forms of ADR.
One of the most important issues on which the IT Expert is asked to give an expert opinion is: what was the quality of the delivered software and was it fit for purpose? This raises the question of: just what is meant by "software quality"? The ready answer from the experienced IT Expert is that "quality" can only mean "fitness for purpose", in the sense of "does the delivered software meet its stated requirements ?"
The "technico-legal litigation tension" common to many such software cases may thus be succinctly expressed as "fitness for purpose vs statement of requirements": it manifests itself in different ways, with a different emphasis, for different specific cases.
For example, in a case concerning an in-store EFTPOS system for a national retailer, the crucial issue was whether or not the software supplier would have fixed outstanding errors and had the system ready to roll-out in time for the pre-Christmas sales rush. What was the objective technical evidence of the software house's "bug find and fix" performance ? Were the bugs escalating, or was the software converging onto a stable, performant system ?
In another case - that of a real-time computer-aided mobilising system for a large metropolitan ambulance service - the focus was on the response times of the software in a clearly life-or-death application. How well were the desired response, availability, reliability and recovery targets for the software contractually defined, and what was the evidence of the system's actual performance under varying load conditions?
I have over the years developed rigorous analytical techniques, Forensic Systems Analysis, for assessing failed, stalled, delayed or generally troublesome software development and implementation projects. This methodology, founded on sound software engineering principles, is objective and impartial, favouring neither customer nor supplier, software user nor software developer. These techniques are becoming internationally known and a brief account was published in Charter (October 2000), the Journal of the Institute of Chartered Accountants in Australia (and will be further explained on the forthcoming website www.ForensicSystemsAnalysis.com).
During software development, functional and performance defects (i.e. failures to meet stated requirements) are routinely encountered, and routinely fixed, and there is generally nothing alarming about their occurrence. For the purposes of rejection of software and termination of a software development contract, any alleged defect must therefore generally be assessed as to whether or not it is truly a material defect, giving rise to a fundamental or repudiatory breach - that is, as to whether or not "the contract cannot be considered to have been performed while this defect persists".
After careful debate, over more than ten years, with many learned and leading Counsel, I use what I now consider is an established sound and secure protocol for testing whether or not any given software fault is, in terms of its relevance to such a breach and termination of a contract, truly a material defect.
This protocol is essentially that, to be a material defect, an alleged software fault must
- be of large consequential effect; and
- be impossible, or take (or have taken) a long time, to fix; and
- be incapable of any practical workaround.
The customer is quite properly entitled to propose what is a "large" consequential effect; and the supplier, equally, may put forward an appropriate sizing for a "long" time to fix - each from his own business/technical knowledge and experience, and in the context of the particular contract/project. Both views ought to be evidentially supportable. Both - and, also, whether or not there is indeed a practical workaround - would be the subject of expert scrutiny and opinion.
This methodology for arriving at an objectively justifiable expert opinion, intended to be of illumination and assistance to the Court, is a good example of IT Expert and Counsel working closely to form a view of a technically complex case which is both rigorous in software engineering terms and clear and compelling in legal terms.
It also emphasises that the earlier the IT Expert and Counsel can work together on a case the better will be the definition of the issues to be resolved, the quicker the narrowing of the key issues, and the lower the cost to the parties - all features welcomed by the Courts. In my experience, IT Experts can be just as adaptable as barristers and both, in my view, should strive to achieve a cost-effective harmony of approach to difficult software development contract disputes.
