Analysis

Are You Requesting the Best Production Format for Your Case? – eDiscovery Best Practices

One of the blogs I read regularly is Ball in your Court from Craig Ball, a previous thought leader interviewee on this blog.  His post from last Tuesday, Are They Trying to Screw Me?, is one that all attorneys that request ESI productions should read.

Ball describes a fairly typical proposed production format, as follows:

“Documents will be produced as single page TIFF files with multi-page extracted text or OCR.  We will furnish delimited IPRO or Opticon load files and will later identify fielded information we plan to exchange.”

Then, he asks the question: “Are they trying to screw you?”  Answer: “Probably not.”  But, “Are you screwing yourself by accepting the proposed form of production?  Yes, probably.”

With regard to producing TIFF files, Ball notes that “Converting a native document to TIFF images is lobotomizing the document.”  The TIFF image is devoid of any of the metadata that provides valuable information about the way in which the document was used, making analysis of the produced documents a much more difficult effort.  Ball sums up TIFF productions by saying “Think of a TIFF as a PDF’s retarded little brother.  I mean no offense by that, but TIFFs are not just differently abled; they are severely handicapped.  Not born that way, but lamed and maimed on purpose.  The other side downgrades what they give you, making it harder to use and stripping it of potentially-probative content.”

Opposing counsel isn’t trying to screw you with a TIFF production.  They just do it because they always provide it that way.  And, you accept it that way because you’ve always accepted it that way.  Ball notes that “You may accept the screwed up proposal because, even if the data is less useful and incomplete, you won’t have to evolve.  You’ll pull the TIFF images into your browser and painstakingly read them one-by-one, just like good ol’ paper; all-the-while telling yourself that what you didn’t get probably wasn’t that important and promising yourself that next time, you’ll hold out for the good stuff—the native stuff.”

We recently ran a blog series called First Pass Review – Of Your Opponent’s Data.  In that series, we discussed how useful that Early Data Assessment/FirstPass Review applications can be in reviewing your opponent’s produced ESI.  At CloudNine Discovery, we use FirstPass®, powered by Venio FPR™ for first pass review – it provides a number of mechanisms that are useful in analyzing your opponent’s produced data.  Capabilities like email analytics and message thread analysis (where missing emails in threads can be identified), synonym searching, fuzzy searching and domain categorization are quite useful in developing an understanding of your opponents production.  However, these mechanisms are only as useful as the data they’re analyzing.  Email analytics, message thread analysis and domain categorization are driven by metadata, so they are useless on TIFF/OCR/data productions.  You can’t analyze what you don’t have.

It’s time to evolve.  To get the most information out of your opponent’s production, you need to request the production in native format.  Opponents are probably not trying to screw you by producing in TIFF format, but you are screwing yourself if you decide to accept it in that format.

So, what do you think?  Do you request native productions from your opponents?  If not, why not?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Don’t Be “Duped”, Files with Different HASH Values Can Still Be the Same – eDiscovery Best Practices

A couple of months ago, we published a post discussing how the number of pages in each gigabyte can vary widely and, to help illustrate the concept, we took one of our blog posts and put it into several different file formats to illustrate how each file had the same content, yet was a different size.  That’s not the only concept that example illustrates.

Content is Often Republished

How many of you have ever printed or saved a file to Adobe Acrobat PDF format?  Personally, I do it all the time.  For example, I “publish” marketing slicks created in Microsoft® Publisher, “publish” finalized client proposals created in Microsoft Word and “publish” presentations created in Microsoft PowerPoint to PDF format regularly.  Microsoft now even includes Adobe PDF as one of the standard file formats to which you can save a file, I even have a free PDF print driver on my laptop, so I can conceivably create a PDF file for just about anything that I can print.  In each case, I’m duplicating the content of the file, but in a different file format designed for publishing that content.

Another way content is republished is via the ubiquitous “copy and paste” capability that is used by so many to duplicate content to another file.  Whether copying part or all of the content, “copy and paste” functionality is essentially available in just about every application to be able to duplicate content from one application to the next or even one file to the next in the same application.

Same Content, Different HASH

When publishing a file to PDF or copying the entire contents of a file to a new file, the contents of the file may be the same, but the HASH value, which is a digital fingerprint that reflects the contents and format of the file, will be different.  So, a Word file and the PDF file published from the Word file may contain the same content, but the HASH value will be different.  Even copying the content from one file to another in the same software program can result in different HASH values, or even different file sizes.  For example, I copied the entire contents of yesterday’s blog post, written in Word, into a brand new Word file.  Not only did they have different HASH values, but they were different sizes – the copied file was 8K smaller than the original.  So, these files, while identical in content, won’t be considered “duplicates” based on HASH value and won’t be “de-duped” out of the collection as a result.  As a result, these files are considered “near-dupes” for analysis purposes, even though the content is essentially identical.

What to Do with the Near-Dupes?

Identifying and culling these essentially identical near-dupes isn’t necessary in every case, but if it is, you’ll need to perform a process that groups similar documents together so that those near-dupes can be identified and addressed.  We call that “clustering”.  For more on the benefits of clustering, check out this blog post.

So, what do you think?  What do you do with “dupes” that have different HASH values?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Daily is Two Years Old Today!

It’s hard to believe that it has been two years ago today since we launched the eDiscoveryDaily blog.  Now that we’ve hit the “terrible twos”, is the blog going to start going off on rants about various eDiscovery topics, like Will McAvoy in The Newsroom?   Maybe.  Or maybe not.  Wouldn’t that be fun!

As we noted when recently acknowledging our 500th post, we have seen traffic on our site (from our first three months of existence to our most recent three months) grow an amazing 442%!  Our subscriber base has nearly doubled in the last year alone!  We now have nearly seven times the visitors to the site as we did when we first started.  We continue to appreciate the interest you’ve shown in the topics and will do our best to continue to provide interesting and useful eDiscovery news and analysis.  That’s what this blog is all about.  And, in each post, we like to ask for you to “please share any comments you might have or if you’d like to know more about a particular topic”, so we encourage you to do so to make this blog even more useful.

We also want to thank the blogs and publications that have linked to our posts and raised our public awareness, including Pinhawk, The Electronic Discovery Reading Room, Unfiltered Orange, Litigation Support Blog.com, Litigation Support Technology & News, Ride the Lightning, InfoGovernance Engagement Area, Learn About E-Discovery, Alltop, Law.com, Justia Blawg Search, Atkinson-Baker (depo.com), ABA Journal, Complex Discovery, Next Generation eDiscovery Law & Tech Blog and any other publication that has picked up at least one of our posts for reference (sorry if I missed any!).  We really appreciate it!

We like to take a look back every six months at some of the important stories and topics during that time.  So, here are some posts over the last six months you may have missed.  Enjoy!

We talked about best practices for issuing litigation holds and how issuing the litigation hold is just the beginning.

By the way, did you know that if you deleted a photo on Facebook three years ago, it may still be online?

We discussed states (Delaware, Pennsylvania and Florida) that have implemented new rules for eDiscovery in the past few months.

We talked about how to achieve success as a non-attorney in a law firm, providing quality eDiscovery services to your internal “clients” and how to be an eDiscovery consultant, and not just an order taker, for your clients.

We warned you that stop words can stop your searches from being effective, talked about how important it is to test your searches before the meet and confer and discussed the importance of the first 7 to 10 days once litigation hits in addressing eDiscovery issues.

We told you that, sometimes, you may need to collect from custodians that aren’t there, differentiated between quality assurance and quality control and discussed the importance of making sure that file counts add up to what was collected (with an example, no less).

By the way, did you know the number of pages in a gigabyte can vary widely and the same exact content in different file formats can vary by as much as 16 to 20 times in size?

We provided a book review on Zubulake’s e-Discovery and then interviewed the author, Laura Zubulake, as well.

BTW, eDiscovery Daily has had 150 posts related to eDiscovery Case Law since the blog began.  Fifty of them have been in the last six months.

P.S. – We still haven’t missed a business day yet without a post.  Yes, we are crazy.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Best Practices: Quality Control, Making Sure the Numbers Add Up

 Yesterday, we wrote about tracking file counts from collection to production, the concept of expanded file counts, and the categorization of files during processing.  Today, let’s walk through a scenario to show how the files collected are accounted for during the discovery process.

Tracking the Counts after Processing

We discussed the typical categories of excluded files after processing – obviously, what’s not excluded is available for searching and review.  Even if your approach includes a technology assisted review (TAR) methodology such as predictive coding, it’s still likely that you will want to do some culling out of files that are clearly non-responsive.

Documents during review may be classified in a number of ways, but the most common ways to classify documents as to whether they are responsive, non-responsive, or privileged.  Privileged documents are also typically classified as responsive or non-responsive, so that only the responsive documents that are privileged need be identified on a privilege log.  Responsive documents that are not privileged are then produced to opposing counsel.

Example of File Count Tracking

So, now that we’ve discussed the various categories for tracking files from collection to production, let’s walk through a fairly simple eMail based example.  We conduct a fairly targeted collection of a PST file from each of seven custodians in a given case.  The relevant time period for the case is January 1, 2010 through December 31, 2011.  Other than date range, we plan to do no other filtering of files during processing.  Duplicates will not be reviewed or produced.  We’re going to provide an exception log to opposing counsel for any file that cannot be processed and a privilege log for any responsive files that are privileged.  Here’s what this collection might look like:

  • Collected Files: 101,852 – After expansion, 7 PST files expand to 101,852 eMails and attachments.
  • Filtered Files: 23,564 – Filtering eMails outside of the relevant date range eliminates 23,564 files.
  • Remaining Files after Filtering: 78,288 – After filtering, there are 78,288 files to be processed.
  • NIST/System Files: 0 – eMail collections typically don’t have NIST or system files, so we’ll assume zero files here.  Collections with loose electronic documents from hard drives typically contain some NIST and system files.
  • Exception Files: 912 – Let’s assume that a little over 1% of the collection (912) is exception files like password protected, corrupted or empty files.
  • Duplicate Files: 24,215 – It’s fairly common for approximately 30% of the collection to include duplicates, so we’ll assume 24,215 files here.
  • Remaining Files after Processing: 53,161 – We have 53,161 files left after subtracting NIST/System, Exception and Duplicate files from the total files after filtering.
  • Files Culled During Searching: 35,618 – If we assume that we are able to cull out 67% (approximately 2/3 of the collection) as clearly non-responsive, we are able to cull out 35,618 files.
  • Remaining Files for Review: 17,543 – After culling, we have 17,543 files that will actually require review (whether manual or via a TAR approach).
  • Files Tagged as Non-Responsive: 7,017 – If approximately 40% of the document collection is tagged as non-responsive, that would be 7,017 files tagged as such.
  • Remaining Files Tagged as Responsive: 10,526 – After QC to ensure that all documents are either tagged as responsive or non-responsive, this leaves 10,526 documents as responsive.
  • Responsive Files Tagged as Privileged: 842 – If roughly 8% of the responsive documents are privileged, that would be 842 privileged documents.
  • Produced Files: 9,684 – After subtracting the privileged files, we’re left with 9,684 responsive, non-privileged files to be produced to opposing counsel.

The percentages I used for estimating the counts at each stage are just examples, so don’t get too hung up on them.  The key is to note the numbers in red above.  Excluding the interim counts in black, the counts in red represent the different categories for the file collection – each file should wind up in one of these totals.  What happens if you add the counts in red together?  You should get 101,852 – the number of collected files after expanding the PST files.  As a result, every one of the collected files is accounted for and none “slips through the cracks” during discovery.  That’s the way it should be.  If not, investigation is required to determine where files were missed.

So, what do you think?  Do you have a plan for accounting for all collected files during discovery?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Best Practices: Quality Control, It’s a Numbers Game

Previously, we wrote about Quality Assurance (QA) and Quality Control (QC) in the eDiscovery process.  Both are important in improving the quality of work product and making the eDiscovery process more defensible overall.  For example, in attorney review, QA mechanisms include validation rules to ensure that entries are recorded correctly while QC mechanisms include a second review (usually by a review supervisor or senior attorney) to ensure that documents are being categorized correctly.  Another overall QC mechanism is tracking of document counts through the discovery process, especially from collection to production, to identify how every collected file was handled and why each non-produced document was not produced.

Expanded File Counts

Scanned counts of files collected are not the same as expanded file counts.  There are certain container file types, like Outlook PST files and ZIP archives that exist essentially to store a collection of other files.  So, the count that is important to track is the “expanded” file count after processing, which includes all of the files contained within the container files.  So, in a simple scenario where you collect Outlook PST files from seven custodians, the actual number of documents (emails and attachments) within those PST files could be in the tens of thousands.  That’s the starting count that matters if your goal is to account for every document in the discovery process.

Categorization of Files During Processing

Of course, not every document gets reviewed or even included in the search process.  During processing, files are usually categorized, with some categories of files usually being set aside and excluded from review.  Here are some typical categories of excluded files in most collections:

  • Filtered Files: Some files may be collected, and then filtered during processing.  A common filter for the file collection is the relevant date range of the case.  If you’re collecting custodians’ source PST files, those may include messages outside the relevant date range; if so, those messages may need to be filtered out of the review set.  Files may also be filtered based on type of file or other reasons for exclusion.
  • NIST and System Files: Many file collections also contain system files, like executable files (EXEs) or Dynamic Link Library (DLLs) that are part of the software on a computer which do not contain client data, so those are typically excluded from the review set.  NIST files are included on the National Institute of Standards and Technology list of files that are known to have no evidentiary value, so any files in the collection matching those on the list are “De-NISTed”.
  • Exception Files: These are files that cannot be processed or indexed, for whatever reason.  For example, they may be password-protected or corrupted.  Just because these files cannot be processed doesn’t mean they can be ignored, depending on your agreement with opposing counsel, you may need to at least provide a list of them on an exception log to prove they were addressed, if not attempt to repair them or make them accessible (BTW, it’s good to establish that agreement for disposition of exception files up front).
  • Duplicate Files: During processing, files that are exact duplicates may be put aside to avoid redundant review (and potential inconsistencies).  Some exact duplicates are typically identified based on the HASH value, which is a digital fingerprint generated based on the content and format of the file – if two files have the same HASH value, they have the same exact content and format.  Emails (and their attachments) may be identified as duplicates based on key metadata fields, so an attachment cannot be “de-duped” out of the collection by a standalone copy of the same file.

All of these categories of excluded files can reduce the set of files to actually be searched and reviewed.  Tomorrow, we’ll illustrate an example of a file set from collection to production to illustrate how each file is accounted for during the discovery process.

So, what do you think?  Do you have a plan for accounting for all collected files during discovery?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Milestones: Our 500th Post!

One thing about being a daily blog is that the posts accumulate more quickly.  As a result, I’m happy to announce that today is our 500th post on eDiscoveryDaily!  In less than two years of existence!

When we launched on September 20, 2010, our goal was to be a daily resource for eDiscovery news and analysis and we have done our best to deliver on that goal.  During that time, we have published 144 posts on eDiscovery Case Law and have identified numerous cases related to Spoliation Claims and Sanctions.   We’ve covered every phase of the EDRM life cycle, including:

We’ve discussed key industry trends in Social Media Technology and Cloud Computing.  We’ve published a number of posts on eDiscovery best practices on topics ranging from Project Management to coordinating eDiscovery within Law Firm Departments to Searching and Outsourcing.  And, a lot more.  Every post we have published is still available on the site for your reference.

Comparing our first three months of existence with our most recent three months, we have seen traffic on our site grow an amazing 442%!  Our subscriber base has nearly doubled in the last year alone!

And, we have you to thank for that!  Thanks for making the eDiscoveryDaily blog a regular resource for your eDiscovery news and analysis!  We really appreciate the support!

I also want to extend a special thanks to Jane Gennarelli, who has provided some wonderful best practice post series on a variety of topics, ranging from project management to coordinating review teams to learning how to be a true eDiscovery consultant instead of an order taker.  Her contributions are always well received and appreciated by the readers – and also especially by me, since I get a day off!

We always end each post with a request: “Please share any comments you might have or if you’d like to know more about a particular topic.”  And, we mean it.  We want to cover the topics you want to hear about, so please let us know.

Tomorrow, we’ll be back with a new, original post.  In the meantime, feel free to click on any of the links above and peruse some of our 499 previous posts.  Maybe you missed some?  😉

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Case Law: No Kleen Sweep for Technology Assisted Review

For much of the year, proponents of predictive coding and other technology assisted review (TAR) concepts have been pointing to three significant cases where the technology based approaches have either been approved or are seriously being considered.  Da Silva Moore v. Publicis Groupe and Global Aerospace v. Landow Aviation are two of the cases, the third one is Kleen Products v. Packaging Corp. of America.  However, in the Kleen case, the parties have now reached an agreement to drop the TAR-based approach, at least for the first request for production.

Background and Debate Regarding Search Approach

On February 21, the plaintiffs asked Magistrate Judge Nan Nolan to require the producing parties to employ a technology assisted review approach (referred to as “content-based advanced analytics,” or CBAA) in their production of documents for discovery purposes.

In their filing, the plaintiffs claimed that “[t]he large disparity between the effectiveness of [the computer-assisted coding] methodology and Boolean keyword search methodology demonstrates that Defendants cannot establish that their proposed [keyword] search methodology is reasonable and adequate as they are required.”  Citing studies conducted between 1994 and 2011 claimed to demonstrate the superiority of computer-assisted review over keyword approaches, the plaintiffs claimed that computer-assisted coding retrieved for production “70 percent (worst case) of responsive documents rather than no more than 24 percent (best case) for Defendants’ Boolean, keyword search.”

In their response, the defendants contended that the plaintiffs “provided no legitimate reason that this Court should deviate here from reliable, recognized, and established discovery practices” in favor of their “unproven” CBAA methods. The defendants also emphasized that they have “tested, independently validated, and implemented a search term methodology that is wholly consistent with the case law around the nation and that more than satisfies the ESI production guidelines endorsed by the Seventh Circuit and the Sedona Conference.” Having (according to their briefing) already produced more than one million pages of documents using their search methods, the defendants conveyed outrage that the plaintiffs would ask the court to “establish a new and radically different ESI standard for cases in this District.”

Stipulation and Order

After “a substantial number of written submissions and oral presentations to the Court” regarding the search technology issue, “in order to narrow the issues, the parties have reached an agreement that will obviate the need for additional evidentiary hearings on the issue of the technology to be used to search for documents responsive to the First Requests.”  That agreement was memorialized this week in the Stipulation and Order Relating to ESI Search (link to stipulation courtesy of Law.com).  As part of that agreement, the plaintiffs have withdrawn their demand that the defendants apply CBAA to the first production request (referred to in the stipulation as the “First Request Corpus”).

As for productions beyond the First Request Corpus, the plaintiffs also agreed not to “argue or contend” that the defendants should be required to CBAA or “predictive coding” with respect to any requests for production served on any defendant prior to October 1, 2013.  As for requests for production served after October 1, 2013, it was agreed that the parties would “meet and confer regarding the appropriate search methodology to be used for such newly collected documents”, with the ability for either party to file a motion if they can’t agree.  So, there will be no TAR-based approach in the Kleen case, at least until next October.

So, what do you think?  Does this signal a difficulty in obtaining approval for TAR-based approaches?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Best Practices: For Successful Predictive Coding, Start Randomly

Predictive coding is the hot eDiscovery topic of 2012, with three significant cases (Da Silva Moore v. Publicis Groupe, Global Aerospace v. Landow Aviation and Kleen Products v. Packaging Corp. of America) either approving or considering the use of predictive coding for eDiscovery.  So, how should your organization begin when preparing a collection for predictive coding discovery?  For best results, start randomly.

If that statement seems odd, let me explain.

Predictive coding is the use of machine learning technologies to categorize an entire collection of documents as responsive or non-responsive, based on human review of only a subset of the document collection.  That subset of the collection is often referred to as the “seed” set of documents.  How the seed set of documents is derived is important to the success of the predictive coding effort.

Random Sampling, It’s Not Just for Searching

When we ran our series of posts (available here, here and here) that discussed the best practices for random sampling to test search results, it’s important to note that searching is not the only eDiscovery activity where sampling a set of documents is a good practice.  It’s also a vitally important step for deriving that seed set of documents upon which the predictive coding software learning decisions will be made.  As is the case with any random sampling methodology, you have to begin by determining the appropriate sample size to represent the collection, based on your desired confidence level and an acceptable margin of error (as noted here).  To ensure that the sample is a proper representative sample of the collection, you must ensure that the sample is performed from the entire collection to be predictively coded.

Given the debate in the above cases regarding the acceptability of the proposed predictive coding approaches (especially Da Silva Moore), it’s important to be prepared to defend your predictive coding approach and conducting a random sample to generate the seed documents is a key step to defensibility of that approach.

Then, once the sample is generated, the next key to success is the use of a subject matter expert (SME) to make responsiveness determinations.  And, it’s important to conduct a sample (there’s that word again!) of the result set after the predictive coding process to determine whether the process achieved a sufficient quality in automatically coding the remainder of the collection.

So, what do you think?  Do you start your predictive coding efforts “randomly”?  You should.  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Trends: Use of Internet-Based Tools, Predictive Coding, Up in 2012, Says ABA

According to a recently released report from the American Bar Association (ABA), use of Internet-based electronic discovery tools and predictive coding has risen in 2012.  The 2012 ABA Legal Technology Survey Report: Litigation and Courtroom Technology (Volume III) discusses the use of technology related to litigation, ranging from hardware used in the courtroom to technology related to eDiscovery and e-filing. It includes a trend report summarizing this year’s notable results and highlighting changes from previous years.

Statistical Highlights

Here are some of the notable stats from the ABA study:

Use of Internet-based eDiscovery and Litigation Support

  • 44% of attorneys whose firm had handled an eDiscovery case said they had used Internet-based eDiscovery tools (up from 31% in 2011 – a 42% rise in usage);
  • In sole practitioner firms, 33% of attorneys said they had used Internet-based eDiscovery tools whereas nearly 67% of attorneys in large firms (500 or more attorneys) indicated they had used those tools;
  • 35% of attorneys said they had used Internet-based litigation support software (up from 24% in 2011 – a 46% rise in usage).

Use of Desktop-based eDiscovery and Litigation Support

  • Use of Desktop-based eDiscovery rose from 46% to 48% (just a 4% rise in usage) and use of Desktop-based Litigation Support remained the same at 46%.

Use of Predictive Coding Technology

  • 23% of those attorneys said they had used predictive coding technology to process or review ESI (up from 15% in 2011 – a 53% rise in usage);
  • Of the firms that have handled an eDiscovery case, only 5% of sole practitioners and only 6% of firms with less than 10 attorneys indicated they had used predictive coding technology whereas nearly 44% of attorneys in large firms said they used predictive coding.

Outsourcing

  • 44% of attorneys surveyed indicated that they outsourced work to eDiscovery consultants and companies (slightly down from 45% in 2011 – a 2% drop);
  • Outsourcing to computer forensics specialists remained unchanged at 42%, according to the survey;
  • On the other hand, 25% of respondents indicated that they outsource to attorneys in other firms (up from 16% in 2011 – a 56% rise!).  Hmmm…

All percentages rounded.

The 2012 ABA Legal Technology Survey Report is comprised of six volumes, with eDiscovery results discussed in Volume III (link above), which can be purchased from the ABA for $350 (or $300 if you’re an ABA member).  If you’re just interested in the trend report, the cost for that is $55 ($45 for ABA members).

So, what do you think?  Any surprises?  Do those numbers reflect your own usage of the technologies and outsourcing patterns?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Best Practices: Assessing Your Data Before Meet and Confer Shouldn’t Be Expensive

So, you’re facing litigation and you need help from an outside provider to “get your ducks in a row” to understand how much data you have, how many documents have hits on key terms and estimate the costs to process, review and produce the data so that you’re in the best position to negotiate appropriate terms at the Rule 26(f) conference (aka, meet and confer).  But, how much does it cost to do all that?  It shouldn’t be expensive.  In fact, it could even be free.

Metadata Inventory

Once you’ve collected data from your custodians, it’s important to understand how much data you have for each custodian and how much data is stored on each media collected.  You should also be able to break the collection down by file type and by date range.  A provider should be able to process the data and provide a metadata inventory of the collected electronically stored information (ESI) that enables the inventory to be queried by:

  • Data source (hard drive, folder, or custodian)
  • Folder names and sizes
  • File names and sizes
  • Volume by file type
  • Date created and last date modified

When this done prior to the Rule 26(f) conference, it enables your legal team to intelligently negotiate at the conference by understanding the potential volume (and therefore potential cost) of including or excluding certain custodians, document types, or date ranges in the discovery order.

Word Index of the Collection

Want to get a sense of how many documents mention each of the key players in the case?  Or, how many mention the key issues?  After a simple index of the data, a provider should be able to at least provide a consolidated report of all the words (not including stop words, of course), from all sources that includes number of occurrences for each word in the collected ESI (at least for files that contain embedded text).  This initial index won’t catch everything – image-only files and exception (e.g., corrupted or password protected) files won’t be included – but it will enable your legal team to intelligently negotiate at the meet and confer by understanding the potential volume (and therefore potential cost) of including or excluding certain key words in the discovery order.

eDiscovery Budget Worksheet

Loading the metadata inventory into an eDiscovery budget worksheet that includes standard performance data (such as document review production statistics) and projected billing rates and costs can provide a working eDiscovery project budget projection for the case.  This projection can enable your legal team to advise their client of projected costs of the case, negotiate cost sharing or cost burden arguments in the meet and confer, and create a better discovery production strategy.

It shouldn’t be expensive to prepare these items to develop an initial assessment of the case to prepare for the Rule 26(f) conference.  In fact, the company that I work for, CloudNine Discovery, provides these services for free.  But, regardless who you use, it’s important to assess your data before the meet and confer to enable your legal team to understand the potential costs and risks associated with the case and negotiate the best possible approach for your client.

So, what do you think?  What analysis and data assessment do you perform prior to the meet and confer?  Please share any comments you might have or if you’d like to know more about a particular topic.

P.S.: No ducks were harmed in the making of this blog post.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.