Disputes over failed software implementation projects raise interlinked technical and legal issues which are complex, costly, and time-consuming to unravel - whatever the financial size of the claims and counterclaims, the facts and circumstances of the contract between the parties, or the conduct of the project and the management and software development methodologies which may have been used. Such projects are often terminated, with the software rejected, amidst a considerable range and variety of allegations expressed by both supplier and customer. These include allegations of incomplete or inadequate delivery, software defects, database errors, faulty design, operational deficiencies, performance shortfalls, systems instability or unreliability, shifting user or business requirement specifications, poor project management, inadequate systems or acceptance testing, lack of co-operation, delays and cost over-runs. Increasingly, such disputes are ending up in the Courts (or being dealt with by other forms of dispute resolution, such as Mediation or Arbitration), with an IT Expert Witness retained by each party to give an independent opinion on what went wrong technically/managerially, what and how bad are the consequences, what is the final state of the software, and who is to blame.
I have been involved as an independent Expert Witness, in over 100 cases over the past 15 years, for Claimants and Defendants; systems/software customers and suppliers; in the High Court, or in Arbitration and Mediation, and in other forms of Alternative Dispute Resolution. I am also experienced as a (CEDR-trained) Mediator and as an ICC Arbitrator. These have included the software development cases in the English High Court which hold the record for the longest trial (GEC Marconi v LFCDA, 1991-92), where a CASTELL Consultant spent some 40 court days being examined in the witness box in a trial which went on for well over a year; and for the largest claim (£200m+, with £50m counter-claimed, heard briefly in the Technology and Construction Court of the High Court in October 2001 prior to settlement), over the failure of a high-profile Outsourcing Agreement.
The expertise and experience generally required for this software development/implementation contract expert witness work is that of an IT professional skilled in software engineering, implementation and development practice; project management; and information systems strategy and procurement. The work has inter alia these important features:
- Responsibilities and Duties: as an expert, you have responsibilities to your client (and to your instructing solicitor) to apply your expertise to (define and) investigate the technical issues on foot between the parties, as thoroughly (but nevertheless cost-effectively) as possible. Your primary duty is however to the court in establishing the 'technical truth' and assisting the court in determining the issues, on an objective and unbiased basis.
- Tasks: these come down essentially to 'investigation, investigation and investigation': of documents, of people, and, most importantly, of the disputed software and system itself (usually the 'best evidence' there is, to the expert).
- Main Deliverable - the Expert's Report: this is the fundamental reason why the IT Expert Witness is there - to produce a thorough and well-rounded report, written in clear English, explaining the expert investigations carried out, the analysis of the evidence, the IT software engineering principles (and industry custom and practice) which have been applied, and, finally,
- Providing Opinions on the key technical issues which lie at the heart of the case. The Expert Witness is the only person in the litigation (aside from the Judge!) who is entitled to give opinion evidence (rather than factual evidence). Such opinions must be objectively justified wherever possible, unequivocally stated ('on the one hand, on the other hand' formulations generally have no place in Expert's Reports), and compellingly expressed. 'If you haven't yet reached a firm opinion, you haven't yet done the work' is a good principle to go by as an expert. Mind you, you do not always get the budget to do all the work you would like...
- ...and so to... Fees/Costs: as an expert (or consultant, or AICS member), you always have to remember that 'one man's fees are another man's costs'. In expert work, you have an additional guiding principle which all involved in litigation have to follow, arising from the Civil Procedure Rules - namely, that costs must also be 'proportionate' (for example, you must be careful not to embark on work likely to cost £0.5m in professional fees for a case where the claim is only for, say, £0.25m). This is not always an easy principle to observe in software development cases, where the difficulty and effort of investigating technically complex issues of software design, construction, testing, functioning, performance etc can in many ways be just as great for a £100,000 'customised off the shelf package' incomplete implementation as it can for a failed £10m bespoke software development project. This problem is lessened by, wherever possible, agreeing with the expert on the other side a core List of Issues; and also producing joint statements on matters where experts can agree, thus taking areas of the dispute out of issue and reducing the need for investigation (and the associated costs) of those particular points.
It is worth saying a few words on what an IT Expert is
not:
- An Advocate: you are not there to argue your client's case - there are already enough expensive lawyers on the case to do that! Seriously, the courts take a dim view of experts straying into advocacy: the Judge essentially wants you as his independent 'partner', providing clear understanding, explanation and opinion, in a dispassionate and non-partisan fashion, so that he may gain determinative illumination and insight into complex technical matters. If, for example, your true opinion is that you cannot support (all of) your own client's claims or counter-claims, then you must say so, and say it early, clearly and unequivocally.
- A Narrow Technical Specialist: disputes over software development or implementation contracts can often call for some narrow specialist technical expertise (e.g practical experience of and proficiency with a particular software development language, RDBMS, toolset etc), but limited technical specialisation of this type is generally not sufficient for arriving at the full-bodied opinion on the usual range of technical issues in such cases which is necessary in order for that opinion to be credible and therefore valuable to the court. When I am appointed expert on some larger cases, I may make use of a team of other consultants, including technical specialists with particular skills and proficiencies to assist in technical investigations. At the end of the day, however, I have to direct and understand the rationale for and results of such work, be personally convinced of the conclusions reached and thus be able fully to explain, support and 'own' (and be examined in court on) the final opinions I give.
- "I would have done it this way": it is not adequate to provide an opinion expressed simply in this way, however good your own personal record as a software engineer or project manager in the field historically may be. The court needs to be presented with an objective, rational basis for your analysis and how you have reached your conclusions and opinions, underpinned by engineering and project management principles, and/or justifiable statements as to accepted industry custom and practice.
- A software fixer: beware - it can be a temptation for an expert team to stray into 'trying to put the failed project right' mode when carrying out their investigations. To give a strong, analysed and justified opinion in your Expert's Report on whether or not some particular software behaviour is a serious fault does not generally require you first to find, test etc the fix for it and put the software right!
- An academic ('custom and practice; not theory'): it is true that for some types of IT litigation, background and experience as an academic (e.g as a Professor of Computer Science or Software Engineering at a British University) can be useful (e.g. some Intellectual Property, and 'hacking', cases). However, in my experience, most commercial software development/implementation contract disputes are really looking for assistance from the type of opinion that comes from the 'grey hairs and scars' of real-world project involvements (and failures!), and seasoned practical project management experience serving actual paying customers/clients, which (only?) years of working as an information systems practitioner can give you...
Succinctly, the typical scope of work as an Expert Witness in such disputes is framed by consideration of the following:
What investigations should be done? At the start of looking at a case, it can be confusing to the inexperienced to know just where to start applying your (costly) expertise...
What evidence should be considered? Usually (but by no means always!) there is already assembled a (large) portfolio of project and technical documents by the time the Expert Witness is hired. So the first task is - read all the documents. Equally, the first task is - identify and request all the documents you don't yet have but you think should be in existence for a software project of this nature. And another first task is - interview as many of the key people, singly, as you can in the shortest time.
The software itself: 'best evidence'? 'Let the software speak for itself'. Much of the work of an expert, when the disputed software/system is still available to be tested (not always the case), consists of identifying, planning, preparing and running appropriate expert testing (usually jointly with the expert for the other side) to demonstrate the presence (or absence) of the alleged faults in (or enhancements to) the system which are often at the heart of the dispute. The results of such testing can have a dramatic effect on the continuation of the action - and, in my experience, it is not unknown for even the suggestion of rigorous independent expert testing of the software itself (perhaps proposed as to be carried out 'before the Judge') to hasten a satisfactory settlement of the dispute...
What is your opinion? Ultimately, to repeat, this is why you have been hired! If you are not the sort of person who can reach a firm opinion, with objectively good, rational, defensible analysis to back it up, and expressed in compelling, clear English - and be prepared to defend your position, convincingly and unshakeably, when cross-examined on it in court, then...
Settlement! or 'Good experts don't go to court'. Just as the Observer Corps' motto is 'Time spent in reconnaissance is never wasted', in my experience, that for IT software contract disputes runs: 'Money spent on a good expert is never wasted'. In the vast majority of all the cases in which I have been involved as an Expert Witness, it is certainly true to say that a satisfactory settlement of the dispute was achieved between the parties shortly after serving of my Expert's Report, so that there was no further need to proceed to trial - in itself resulting in a huge saving in costs to both sides.
One of the most important issues on which you are almost always asked to give an expert opinion in these cases is: what was the quality of the delivered software and was it fit for purpose ? To answer this, CASTELL Consulting has over the years developed a range of rigorous analytical techniques, Forensic Systems Analysis, for assessing failed, stalled, delayed or generally troublesome software development and implementation projects. These techniques, founded on sound software engineering principles, are objective and impartial, favouring neither customer nor supplier, software user nor software developer. This objective and unbiased approach is precisely that demanded of the Expert Witness, whose primary duty, as I have noted, is to the Court in finding the 'technical truth'. It is particularly important technically where software projects involve a mixture of 'customised' software packages and 'bespoke' software construction. These techniques are becoming internationally accepted and an account of the Forensic Systems Analysis methodology was published in the October 2000 issue of Charter, the Journal of the Institute of Chartered Accountants in Australia; and in the October 2001 issue of the UK Barrister magazine. It is my intention that they will be further developed and promulgated, as a contribution to good IT professional practice, on my future website www.ForensicSystemsAnalysis.com.
Members of the AICS could well consider developing their careers in the Expert Witness direction - if they have wide experience, can be technically rigorous and independent in thought, critically objective and, above all, write clear, good English. One of the best ways to get started in this field is to work with an established consultant who frequently does expert work. I myself am always interested in hearing from independent software practitioners with particular expertise and interests who could for example assist on some of the larger projects where an expert team is necessary. Bodies like the Expert Witness Institute, and the Law Society (which publishes an annual Directory of 'checked' Expert Witnesses), welcome IT consultants and contractors who have had some practical experience of expert witness work.
