I like to talk about document review workflow as early as possible in any eDiscovery document review project I manage. It’s important not only because it’s helpful for the reviewing attorneys to understand how their coding decisions will shape the end result, but also to explore how we can use workflow to navigate technical or strategic considerations particular to a given matter. While case-specific workflows will inevitably vary, I thought I’d kick off this blog by sharing an example workflow design, which I’ve found to stand as a great starting point for just about any linear document review project.
Two caveats: first, the document review workflow I’m talking about is used in Relativity review environments and, therefore, certain document review platforms might lack features necessary to achieve this exact result. For example, older or less developed document review platforms do not let you create different coding field types such as SingleChoice, MultipleChoice, Text, or TextArea. Instead, there’s just a single “tag” field, which is less than ideal. Second, this workflow assumes that you will be producing all documents, and their families, marked responsive minus anything withheld, and their families (i.e. anything coded privileged). For example, emails and their attachments will be reviewed and produced (or withheld) together. If you don’t understand what I mean, consider the following examples:
Here, we would produce all four documents because one document is coded Responsive and there are no reasons to withhold the family (i.e. there are no other family members tagged with a value indicating privilege).
Here, we would withhold all four documents because although one document is coded responsive, another family member is coded as being privileged.
Here, we would not produce any documents because none are coded responsive. Whether or not one document is coded as being privileged is irrelevant.
Producing documents in incomplete families is just bad practice and should be avoided wherever possible. This basic review workflow assumes that at least one of your underlying goals is to do a good job administering a simple linear document review project. Therefore, we aren’t going to engage in behavior that will needlessly add complexity and generate confusion.
As in the examples above, you can think of documents and their associated metadata as a simple table like what you would see in an Excel spreadsheet. There are columns (named by each field) and rows, which contain the attributes (values) relating to each document. It’s really that simple – everything is just columns and rows. At the end of the day, we’re just talking about moving virtual pieces of paper around in a virtual space based on a combination of just a few basic rules that look to the fields and their values. Here’s a visual representation of this workflow, which serves as a blueprint for this entire discussion.
It’s very easy to create this workflow within Relativity (and presumably many other review platforms). All you need are a coding layout (requires creation of fields and choices), a number of searches that return the desired combinations of fields and choices, and a review team that understands and appreciates the production logic discussed above. You will be producing all documents and their families that are tagged Responsive minus all documents and their families that are to be withheld (i.e. anything coded privileged). For the coding layout, start with the following:
DETERMINATION – (SingleChoice field, REQUIRED field)
- Responsive
- Non-Responsive
- Technical Flaw
- Further Review Required
REVIEW WORKFLOW – (MultipleChoice field)
- Hot Document
- Needs Redaction
PRIVILEGE – (SingleChoice field, REQUIRED field)
- Not Privileged
- Attorney-Client
- Work Product
- Attorney-Client & Work Product
TECHNICAL FLAW REVIEW – (SingeChoice field)
- Corrupt REPROCESS
- No Tech Flaw
- Open Native View
- No Content
- Password Protected
I would recommend binding keystrokes to each choice to expedite review. Next, you should also create the following saved searches as described below because they each return documents meeting the criteria you will be interested in seeing during your review project. For example, the 00. Standard to Produce search will return only complete families that meet production criteria and nothing else. Privileged + Families will always return anything privileged and their families (i.e. everything you want to exclude from production and will likely handle via a privilege log). Here is an overview of the searches I usually like to create:
Standard to Produce
- Includes: Include Family
- (Saved Search) is in All Responsive + Families; AND
- (Saved Search) is not in Privileged + Families; AND
- (Saved Search) is not in Further Review OR Technical Flaw + Families; AND
- (Saved Search) is not in Needs Redaction AND Markup Set Not Set + Families; AND
- ProductionVolume is not set (*because we do not want to include anything previously produced)
Privileged + Families
- Includes: Include Family
- PRIVILEGE = any of these (Attorney-Client OR Work Product OR Attorney-Client & Work Product)
Further Review Required + Families
- Includes: Include Family
- DETERMINATION = Further Review Required
All Responsive + Families
- Includes: Include Family
- DETERMINATION = Responsive
Technical Flaw Review
- DETERMINATION = Technical Flaw; AND
- TECHNICAL FLAW REVIEW is not set
Technical Flaw Reviewed
- TECHNICAL FLAW REVIEW is set; AND
- DETERMINATION is none of these (Responsive OR Non-Responsive)
Further Review OR Technical Flaw + Families
- Includes: Include Families
- DETERMINATION = (Technical Flaw OR Further Review Required)
Needs Redaction AND Markup Set Not Set + Families
- Includes: Include Families
- REVIEW WORKFLOW = Needs Redaction; AND
- Markup Set – Primary is not set
By the way, if you’re administering a review environment that allows you to create new matters based off of a template (e.g. Relativity) it’s a good idea to build all of this into a template in order to encourage a workflow that’s common across all matters. For the next post I hope to write a little bit about the fields, why they’re important, and how we use them to make the most out of this basic workflow design.
Click here if you’d like to learn about our eDiscovery services.
