Potential Problems

This sub-Section details some of the more common issues that can be encountered in using litigation support systems. It is not to say that a software package with one of these problems is automatically excluded from your procurement, there are very often workarounds, but you need to know the issues exist so you can factor them in to your evaluation criteria.

Email Groups #

In the United States it is possible to claim Privilege over an entire email family (that is an email with one or more attachments), this is not the case in the UK and other jurisdictions. However, some of the software packages used to treat the email family as a single entity and did not allow you to split out attachments because they are privileged. This can cause significant overheads at production time and should be an issue you are well aware of when selecting software. Make sure it is a question you ask of the supplier.

Re-unitisation of Images of Paper Documents #

Most of the software on offer comes from a background of handling electronic information, emails, Word documents and the like. Now the one thing a piece of Electronically Stored Information (ESI) never does, is change its boundaries, it is what it is. Compare this with scanning, storing and coding paper based images. With the best will in the world there will be time when the images that make up a paper document need to be re-unitised, that is the coding that encompasses say 6 pages, needs now to be split into two sets of coding, one for the first three pages and one for a second document of the last three pages. Not an issue, I hear you say, we will just split up the images in the software and change the coding as needed. This is where you hit the mind-set of the R&D team for ESI based software. They have no concept of the boundaries changing and so have little, or no functionality for re-unitising paper based records. Paradoxically the “ancient” software of Concordance and original Summation could do this with no problems as they came from a paper based background, it is the “new kids on the block” that have problems.

This won’t affect you, unless you have significant amounts of paper to process for your disclosure exercise, but if you are in that situation, explore with your vendor partner how they will deal with this.

High-level Allocation of Alias for Names Normalisation #

The issue here is the variety of names that appear during collection of emails. Not only do you get people who have different email hosts, so;

andrew.haslam@allvision.co.uk, andrew.haslam@gmail.com, andrew.haslam@etc

Also in Outlook you have the option for a “Display as:”, where you can edit the text in the “Display as” field. I like to differentiate between people’s personal and work email addresses, so I change the text in the “Display as:” field to reflect this, so the entry with an email address of;

andrew.haslam@allvision.co.uk, could be displayed as Andrew Haslam (Work)

Now when an email is collected, the email address shown is Andrew Haslam (Work) not andrew.haslam@allvision.co.uk.

Also if you are collecting email from within an organisation, you can get the SMTP version of this that has all kinds of letters, brackets and punctuation.

Most Early Data Assessment tools are aware of this issue and will allow you to pick a set of names to search on, so if I was trying to get all emails sent by Andrew Haslam, I could tick the boxes to get the all the variants of my name. After a while this gets really boring, particularly when you want to start doing searches of email sent to and from a group of people, each with 4 or more versions of their email address.

What (in the author’s humble opinion) is needed if a facility to have a single alias, to which all the variants could be assigned, and then you could far more easily be able to conduct complex searches. From 2014 onwards some products started to incorporate this functionality into their offerings, with edt being one of the early adopters.

Or, you get the vendor to do all the heavy lifting for you, and you just tell them what you want.

Data Collection by Client or Law Firm’s IT Department #

The short version of this is used to be. Don’t Let Them Do It.

The longer version, is that data collection is not a matter of copying an item of ESI. If you don’t know what you are doing, when you copy something you can change all the metadata associated with a document. What does this mean in the real world?

In one of the cases I was involved in, one set of clients used to present monthly reports to their board using a PowerPoint slide deck that had Excel spreadsheets underpinning all the graphs. The dispute revolved around actions that had taken place in 2006, so copies had been made by someone (client’s IT department, incompetent vendor, some gremlin along the way) of the 2006 PowerPoint shows, sometime in 2010. Except they hadn’t been forensically copied, and all of the shows now had a date displayed on the first slide of sometime in 2010, not the original correct 2006 date. So there we were in 2012, coming late to the case, relying on other people’s efforts and evidence, and the other side kept demanding we give them the 2006 documents and all we had were “tainted” versions with no way of now collecting the originals.

The proposal to self-collect data normally comes from a client wanting to keep their costs down. My advice used to be to caution against this, but most internal IT departments are now technically competent enough to carry out the process, though you need to make sure they are well aware of the potential dangers before you let them do this. Sometimes in-house IT can cope with most of the collection requirements, but need external assistance with the more exotic forms of data, such as that held on mobile phones, or within structured databases such as accountancy systems, etc.

In close second, comes the lawyer, also keen to cut costs who volunteers their in-house IT team to get the information. In most cases, a law firm’s IT department does not have the expertise, the time nor the professional indemnity insurance to be going anywhere near a data collection. Avoid it and get a professional to do the job, then, if it does all go wrong, their insurance can take the hit, not your reputation.

Issues of Working in “Native” Formats #

Most litigation support platform have viewing tools that let you look at Word, Excel and PowerPoint documents without firing up the original software. This is fine for a quick glance, but of no use at all for real review. In a number of the real life cases I’ve been involved in, the text that makes a document Privileged has been contained in the Track Changes comments in a Word Document. (There’s a whole Section’s worth here on organisations that hand over Native documents without scrubbing this kind of data, but that’s for another day). Similarly unless you look at the formula’s and workings of Excel, how can you begin to understand the purpose of the spreadsheet.

The answer to this used to be that people would offer up PDF versions of the ESI. Nowadays that won’t cut it and will be resisted (very strongly) by any half-awake opponent. You need to be aware of the “iceberg” of issues that collecting and review Native data brings, and (at the very least) have protocols built into your review platform so you can see reviewers have downloaded the native document to review it. Plus, that the people doing the review have the technical skills to do things like look in Word Track Changes, or know how to remove the “hide” command in Excel.

A practical point that also occurs with frequency is the case were an email has attachments that contain one or more irrelevant items. If you produce the email to the other side in Native mode, then the email will contain within it, the irrelevant documents. In some cases this doesn’t matter, in others the irrelevant material contains confidential information on organisations or individuals not involved in the litigation. In these instances it is normal practice to produce the email as a multi-page PDF (or as a set of Tiff images), either way as a non-native document.

In the UK you should be aware that the eDisclosure pilot has mandated that the default for exchanging documents should be in native mode, unless there are reasons to use a imaged rendition of the item, such as the need to apply a redaction.