Cohen and Mattingly: ESI review protocols: No more shots in the dark

Cohen

Mattingly

By Hamish Cohen and Jonathan Mattingly

Much has changed from the good old days when associates reviewed documents in huge warehouses. Back then one could stand and survey his or her domain of Bankers Boxes, many of which were gently dusted with what was probably asbestos and had been invariably damaged in some long-forgotten flood or fire. The possibility that your client wrote something damaging (or helpful) in an offhand email was non-existent; the likelihood of someone finding useful documents in some moldy box about the same. We were all, in many ways, shooting in the dark.

Technology has changed things. Big clients no longer open their warehouses to opposing parties and tell them with passive-aggressive glee to enjoy a winter half-frozen with carbon-paper stained fingers looking for goodness-knows-what.

Today, a producing party gathers, processes, reviews and produces information that the receiving party can analyze and search immediately using sophisticated diagnostic software and complex Boolean search protocols. Document productions, if done incorrectly, are often overly and underly broad; unnecessarily expensive and inefficient; and potentially damaging. These days if you, knowingly or unknowingly, produce a needle in a stack of hay, it will be (or should be) found.

Attorneys today must closely monitor client “needles” while still producing responsive documents, removing non-responsive documents and identifying privileged documents. How? You need good document review procedures and protocols. What are good procedures and protocols? The answer to this question, as any experienced lawyer knows, is “it depends.” Fear not; principles exist to guide us.

1. Know your case. Use your case knowledge to develop a written review protocol that introduces the case, explains the relevant legal concepts, reiterates the reviewer’s legal and ethical obligations (their duty of loyalty and confidentiality, for example) and describes on a category-by-category basis how any document should be coded for responsiveness, privilege or in relation to the issues. Provide, as part of the protocol, key documents or document excerpts such the complaint, discovery responses or specific sample documents. Then train the reviewers. Train them thoroughly. Train them in the database you are using. Train them using the protocol and real-world document-based examples. Then train them again.

2. Keep it simple. Complex review protocols take longer to implement, cost more, result in slower review times and introduce more opportunities for error, so keep coding focused and on-point. This includes limiting the number of issue codes for the reviewers to consider. Rather than develop a code for every eventuality, come up with a few overarching categories and perform searches for subsets of documents.

3. Evolve in real time. Accept that your initial protocol will not be perfect (or even close to it). Review protocols must evolve and change as information is learned during the document review. Establish a chain of command through which questions, concerns or documents that require further review (because they are problematic or key) are passed up the chain and information, answers and protocol changes are passed back down to the review team in real time. Don’t just train the review team once. Train them as needed. Communicate these changes to your team through emails and/or at your team meetings. Additionally, keep a log of the questions and the responses provided so consistent feedback is provided.

4. Technology is our friend. We know what you’re thinking. You’re secretly scared of technology — #Idontgetit; #whatisahashtagusedfor. Don’t be afraid of technology. Embrace it. A good review platform permits a more efficient, less-expensive and more accurate document review by permitting data analysis, grouping similar (but not necessarily identical) documents together, and providing easy access to email or document families. Reviewing and coding similar documents together (rather than having them reviewed independently by different reviewers in different custodial mailboxes for example) is faster, cheaper and considerably more accurate because like documents are coded and grouped with other like documents. Technology also can be used to identify documents that are more or less likely to be responsive or more or less likely to be privileged via the use of key terms, custodian-related information or computer-assisted review. Vendors can help you use these tools efficiently.

5. Develop a clear workflow. Any good document review should establish a thorough and efficient workflow diagram for the first pass and second pass review of documents. The workflow diagram should, inter alia, identify what occurs with potentially privileged documents, documents that require redaction, documents that will be marked confidential pursuant to a protective order or agreement, and “hot” documents that address key points or issues in the litigation.

6. Quality control matters. Implement substantive and technical quality-control procedures. As to the former, have someone who really understands the case review a statistically relevant sample of reviewed and coded documents right at the outset. Doing so provides a critical opportunity to provide the review team with immediate real-world feedback so as to improve the review quality from the outset. As to the latter, technology can help ensure that the review and any production is complete and consistent (or prove that the other side’s production was neither).

These protocols and procedures require up-front work, but in the long run they save a tremendous amount of time and money while improving review results. Implement them and you’ll no longer be shooting in the dark.•

? Hamish Cohen and Jonathan Mattingly are founding partners and directors of the law firm of Mattingly Burke Cohen & Biederman LLP and ESI consultant Proteus Discovery Group LLC. Through both companies, Hamish and Jon bring their experience with ESI to work with lawyers and clients in order to manage data protocols and discovery. The opinions expressed are those of the authors.