Don’t Overlook the Document Review Guidelines

Ever lead a team of people and feel as if you were herding cats? Each person on the team has their own concept of what needs to be done and the best method to accomplish the task? Without proper leadership, this team will have little to show for their hard effort at the end of the day because everyone is headed a different direction.

Having spent many years managing electronic discovery projects as eDiscovery counsel, including managing the document review work, I know the importance of keeping everyone on the same page. In the context of a large document review project, that “page” is the document review guidelines.

The document review guidelines initially serve as the training material for the review team and the rules that govern each categorization decision. Not sure if a document is relevant? Look at the guidelines. Not sure if the document should be tagged as “Highly Confidential” or merely “Confidential” per the protective order? Look at the guidelines.

Guidelines are an essential part of a well managed document review project. Yet, they are often not given the attention they deserve. Here are a few suggestions for developing guidelines for your project:

• Content: How much detail should you include in the guidelines? The guidelines should give the person categorizing documents a one stop resource for document categorization rules. The goal is to avoid having the reviewer flipping through multiple documents and notes to determine how to categorize a document. You will likely want to provide the review team reference and background material that is relevant to the case, e.g. fact summaries, org charts or notes taken from interviewing employees whose documents will be reviewed. However, this information is often better suited as an appendix to keep document review guidelines streamlined and functional.




• Form: The pace of your review team will increase if your guidelines flow chronologically through the logical decision making process and track with the coding form in the database. When drafting guidelines for my cases, I use input from the document requests, the client and the litigation team to draw a flow chart on a whiteboard and then draft the guidelines to match. Document review guidelines are typically broken out into sections; Disposition (Responsive, Privileged, Not Responsive or Not Sure), Confidentiality (Not Confidential, Confidential or Highly Confidential) and other categories as needed.




• Timing: The document review guidelines should be as complete as possible before the document review portion of the project begins. Otherwise, you may unnecessarily waste time (and money) re-reviewing documents later when issues are clarified. When you are tempted to begin a large scale document review project without clear guidelines refer to my “herding cats” comment above.

  

• Input: It is important to get sufficient “buy-in” on the guidelines prior to starting review so both substance and form are effective. The litigation team needs to understand what the review team is identifying (and what they are not identifying) so they are getting the information they need to prepare for depositions and trial. Likewise, someone who has managed many eDiscovery projects will be able to tell you whether your guidelines are clear and streamlined or overly detailed and unwieldy – the latter will lead to sluggish review times and increased cost.




• Guideline Changes: The guidelines will change throughout the project regardless of the level of effort to finalize them in advance of the review. One of the important benefits a review team provides is a line-of-sight into the contents of the documents. After a week or two of reading email and documents, the review team will likely know the overall document set better than most of the client employees. With the benefit of the knowledge gained through this review, new trial themes, claims and strategies may emerge – and as a result the guidelines will change.




• Version Control: Update the document review guidelines periodically as new information surfaces. For example, most review guidelines will instruct the reviewer to code a document as “hot” if it falls within a list of categories. Update the guidelines as the list of categories evolves over the course of the project. Use date and version control on your guidelines so you have the ability to later track which guidelines governed your document review at specific points in time.

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•