eDiscovery Daily Blog

• April 4, 2017

Here’s a big “pothole” that can derail your eDiscovery project.  On Thursday, I’ll discuss how you can learn about several more “pitfalls” and “potholes” and how to avoid them.

As soon as litigation is anticipated, it’s a good idea to begin collecting potentially responsive data and assessing it by performing searches and testing the results.  Because, if you wait until after the meet and confer with opposing counsel to do so, it can be expensive.

On the very first day we introduced eDiscovery Daily over 6 1/2 years ago, we published a post where we discussed the danger of using wildcards in your searches (and how they can retrieve vastly different results than you intended).  I was providing search strategy assistance to a client that had already agreed upon over 200 search terms with opposing counsel.  The attorneys had prepared these terms without assistance from a technology consultant (or “geek” if you prefer) – I was brought into the project after the terms were negotiated and agreed upon – and without testing any of the terms.

One of those searches related to mining activities, so the attorney decided to use a wildcard of “min*” to retrieve variations like “mine”, “mines” and “mining”.  As you know by now if you’ve been a reader of the blog since the beginning (or if you clicked on the link to that original post above), that one search retrieved over 300,000 files with hits because there are 269 words in the English language that begin with the letters “min”.  We ultimately had to go back to opposing counsel and attempt to negotiate a revised search that was more appropriate.

Since the terms had been agreed upon, opposing counsel was understandably resistant to modifying any of them.  It wasn’t their problem that my client faced having to review all of these files – it was my client’s proposed term that they now wanted to modify.  However, because we were able to demonstrate a clear indication that many of the retrieved documents in this search were non-responsive, we were able to get opposing counsel to agree to a modified list of variations of “mine” that included “minable”, “minefield”, “minefields”, “miner” and “minings” (among other variations).  That modified search reduced the result set to less than 12,000 files with hits, saving our client a “mint”, which they certainly didn’t “mind” (because we were able to drop “mint” and “mind” and over 200 other words from the responsive hit list).

However, there were several other inefficient terms that opposing counsel refused to renegotiate and my client was forced to review tens of thousands of additional files (costing tens of thousands of dollars) that they wouldn’t have had to review if they had included a technical member on the team at the beginning and had they tested each of these searches before negotiating terms with opposing counsel.  Doing so would have identified which terms were overbroad and would have led to determining more efficient search terms to propose, saving tens of thousands of dollars in review costs.

So, what do you think?  Do you test your search terms before proposing them to opposing counsel?  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. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.