The purpose of the note was to identify the difficulties frequently found in IT litigation (although some of the points are of general application) and to generate discussion and agreement as to how those difficulties may be addressed. IT was not intended to be exhaustive or prescriptive of the type of problems that may arise or the issues and directions that might be considered at a CMC. The following is an edited version of the original note.
Perceived Problems
What are the perceived problems with conducting IT litigation?
(1) One side has all the knowledge, all the documents and all the software:
· If development took place off-site: the client may have no real knowledge of the system, development tools, configuration management or resources. The client has no access to project documentation or software.
· If the development took place on-site: the supplier may have no access to the project system, software, library, e-mails or documents.
(2) There are difficulties in preserving the system and relevant software.
· There is inevitable delay between termination and the issue of proceedings (compliance with protocol = three months plus).
· No thought has been given to nor agreement reached as to what is relevant.
· It is impractical to preserve the system fully, given the need to mitigate. If no preservation, is a fair trial still possible?
(3) Massive documentation (mostly irrelevant) creates enormous costs.
· What documents/disclosure is really required?
· Should disclosure be limited?
· In what format should documents be disclosed?
(4) Documents and e-mails are missing.
Key project personnel have left. Hard drives and e-mail archives of key players have disappeared. The absence of such records generates suspicion and distrust.
(5) There are unhelpful, formulaic Scott Schedules.
· Schedules may be the answer but are of little use if they merely rehearse or regurgitate contemporaneous defect logs or change request logs.
· Schedules are ordered for issues that are not amenable to schedule form.
· Schedules are unwieldy and poorly set out; there is no space for a response or a response is not ordered.
(6) Experts’ joint statements, test results and reports are produced too late and at great cost.
· No one has identified the expert issues. Experts are told to read the papers and get on with it.
· No one has agreed the approach to testing or the tests.
· Joint statements say little: there is no articulation of why there is disagreement.
· Experts are used to interview witnesses and prepare the case for trial.
· Experts reports are exchanged too close to trial.
(7) Multiplication of issues.
· One issue leads to three others. All of them are irrelevant if the first issue is resolved in favour of A.
· Lists of issues do not deal with dependencies but merely summarise the pleadings.
Tools for Resolving Problems
The following activities, information, discussions and directions at the first CMC may go some way towards resolving the issues and mitigating the problems referred to above.
(1) Software and the System
· Identification of the relevant software, software tools, databases and system components.
· Provision of mirror-image copies of the systems/software for both parties as soon as reasonably practicable.
(2) Documents
· Identification and agreement of all common project documents: eg the ITT, response to ITT, specifications, contract/contract documents, minutes of all joint and project meetings (at all levels), invoices, letters and memos passing between the parties. In many cases these documents will have been placed on the project library or in a shared directory – a simple case of copying?
· Identification of documents that the parties do not have in common: eg e-mail archives, internal memos, internal/executive/board minutes and reports, e-diaries, daybooks, time records. Each party might be ordered to disclose for the CMC the categories of documents that they hold and declare the format, paper, electronic (Word, Excel, MS Project, proprietary, e-mail format etc). Whose email archives, for what period? Where are the documents held: desktop, archive, SAN, third party?
· Discussion or agreement to limit disclosure to non-common documents?
· Discussion or agreement to disclose e-mails by individual’s folder (sent and received) in original electronic form.
· Consider disclosure in phases ie copies of systems/software immediately, e-mail folders/archives then other.
(3) Matters relating to Expert Evidence and Tests
· Identification and/or agreement of expert issues. This is probably the most important tool in effective case management and ought to be available for the CMC.
· Identification of investigations likely to be needed, including purpose, feasibility and cost. Where, when and how are they to be carried out? Using what system? As regards software testing (eg if performance is an issue), what tests can be carried out, are they feasible (can you simulate a load of 1,200 users on a call centre/CRM system which is currently in use?
· Identification of software tools that the parties are likely to need to conduct investigations (agreement on licences). For example, configuration systems or project planning software require licences that only the supplier is likely to have. Looking at a project plan in hard copy is generally thought to be of limited value (or useless) because the information is held dynamically.
· Experts’ joint statements and reports to be disclosed well before trial, perhaps at the same time as witness statements.
· Experts should be instructed on either agreed facts or, if they cannot be agreed, assumed facts.
(4) Witnesses and Project Personnel
· Identification of all project staff and potential witnesses. It is thought useful to know who was on the project, their role and the dates when they worked – such information to be produced for the CMC. This is particularly relevant where delay or inadequate resources is the issue.
(5) Quantum, Disclosure and Experts
· Financial schedule of loss and damage and identification of key quantum documents. Frequently the quantum claim is exaggerated: standard procedure should be for the claimant’s schedule and report to be disclosed with supporting documents and for the defendant’s expert to be entitled to seek clarification, explanation and further documents before responding.
(6) Issues
· Identification of issues. There should be issue flowcharts or trees (eg identification of contractual issues or issues of construction and identification of issues on a “so what?” basis).
Reflections on the Note and Further Developments
Electronic disclosure is currently the subject matter of a proposed new practice direction and a recent report of a working party chaired by The Honourable Mr Justice Cresswell dated
Of course, whether or not a standard form agenda should be used for CMCs is a matter for the judges. Irrespective of whether such an agenda is considered appropriate, the primary responsibility for ensuring that the overriding objective is achieved, that trial preparation is effective and that the cost of IT litigation is kept within reasonable bounds, lies with the parties and their lawyers. Obviously, there is a danger in imposing on the parties any sort of checklist or prescribed set of directions, particularly where “agreement” is a key feature of those directions. It might be said that costs will only be increased, particularly where communication between the lawyers is not what it might be and the adversarial nature of our legal system runs hot and strong. On the other hand, if, prior to the first CMC, all parties are aware of what a judge is likely to want to know in order to make effective case management decisions likely to reduce the burden of costs and facilitate settlement, then a standard form agenda may well be justified.
The floor for the debate is open. If you have comments or suggestions on the subject of standard directions for IT cases or ways in which IT litigation can be improved or costs reduced, the SCL would like to know. Please send your comments and views by e-mail to lseastham@aol.com including Standard Directions as the heading.
Alex Charlton is a Barrister at
