A Workflow for Managing Large-Scale Document Reviews

Lawyers don’t like to think of themselves as assembly line workers. It isn’t that legal work is necessarily more complicated than assembly line work. Rather, the reason is that lawyers are trained to be generalists, and as a result they find themselves analyzing complex facts, considering substantive and procedural rules, serving clients’ business objectives, and developing and executing on a strategy—all at the time same. This correspondent sincerely believes that this versatility is one of the defining marks of a great lawyer. Every once and a while, however, the best way to advance the client’s interests is to practice law in an assembly line.

1. The Assembly-Line Concept

The assembly-line model of labor allocation probably dates back to hunter-gatherer times, but history credits the eighteenth-century economist Adam Smith as pioneering the idea. Writing in the eighteenth century, Smith described the manufacture of pins. There are apparently 18 different steps involved in making a pin. If you assign a single person to the task, going step-by-step through the 18 processes, that person will produce at most a handful of pins a week. Likewise, if you assign ten people to the team, each one working in a silo, step-by-step through all 18 process, the team will produce a few dozen of pins per week. However, if each of the members of the team is assigned a single task at a time, then the pin-making process goes exponentially quicker: a team of ten pin-makers, Smith found, could produce some 10,000 pins per week. The assembly line, therefore, transforms a group of individuals into a team that is many, many times better than the sum of its part.

2. A Workflow for a Large-Scale Document Review

Today, the assembly line model applies with equal force to the task of managing large-scale document reviews. Unlike Smith’s pin-makers, however, modern day document reviews have the benefits of supercomputer processing power and technology-assisted review. Take a team of ten attorneys working to review a million documents for production in a civil litigation. Each document needs to be reviewed for responsiveness, for privilege, and, say, for personally identifiable financial or health information (“PII”).

None of these are easy tasks. Reviewing for responsiveness requires interpreting several dozen convoluted document requests. Reviewing for privilege involves keeping a running knowledge of attorney names and roles and client names and roles, and determining whether each document represents a non-waived, confidential communication between lawyer and client for the purposes of requesting or providing legal advice or assistance; or whether the document was prepared by or at the direction of an attorney in anticipation of litigation. The documents that are privileged need to be redacted or withheld; and for each withholding an artful description must be drafted to include on a privilege log. Finally, any documents that contain PII need to be redacted.

In such a case, it is neither efficient nor reliable to have each reviewer work in a silo, performing every task, document-by-document-by-document a million times over. Rather, it is far faster, less expensive, and more accurate to set up a workflow that relies on computers as much as possible, and which allocates human labor in the model of an assembly line. The result looks a little something like this:

This is a “busy” chart, but the idea is simple. A review begins by identifying relevant documents, either through a predictive coding tool or a first-level human review. Reviewers are instructed not to go out of their way to look for privilege issues but, if they notice that a responsive document is likely privileged, to code it as such. In addition to coding for responsiveness, when reviewers come across documents with PII (or foreign language, or technical difficulty, or any of a dozen other things than can come up in a review), they select a “PII” radio button.

Next, you take the universe of relevant documents and run search terms for privileged documents. Sample “privilege” search terms would be lawyers’ names (e.g., Dryden), firm names (Foley near3 Lardner), and firm email protocols (*foley.com). This is not to say that all, or even most, of the documents that contain these search terms are actually privileged; to the contrary, for instance, a copy of this article would hit all three of the terms just listed, but because this article is neither confidential nor legal advice, it is not privileged. Documents that are deemed to be responsive but not privileged are produced; while documents that are privileged are then sent to the next step in the workflow. This second-level privilege review also serves as a double-check for documents with PII.

Documents that are identified as privileged in the first or second rounds get special treatment. Here, it is best to have a designated “priv team” that works closely together to share information and develop a common protocol for privilege logging. Depending on the complexity of the privilege issues in a case, it sometimes makes sense to set up specific sub- workflows within the privilege review. For instance, you might designate some reviewers to do redactions, while others are dedicated to privilege logging. Or, you might use search terms so that one reviewer works on documents that are likely to relate to the Blackacre matter while another works on documents that are likely to relate to the Greenacre matter.

The last attorney step is to do the cleanup. In this case, the chart above envisions a step for redacting documents that contain PII, which can be a very large job in its own right. Each review is different, however, and there are always multiple loose ends at the end.

1. Technology Ties the Workflow Together

Computers assist between each step in the workflow. Whether by advanced analytics or just thoughtful batching, the “arrows” in the workflow above represent critical work that is accurately and rapidly performed by the review platform. As of the date of this writing, predictive coding is able to perform much of the responsiveness coding reflected by the “top” arrows, although predictive coding is not (yet) able to reliably analyze documents for privilege or loose ends such as PII.

One last issue in the workflow is “tiffing” (preparing .TIF images), or whatever last-step imaging is required for non-native productions. Any document that is going to be produced in a non-native production will need to be tiffed eventually, but tiffing takes time and costs money. Wherever avoidable, then, one should not tiff documents that one does not intend to produce, such as privileged documents. In practice, however, the quickest route is often to err on the side of over-tiffing, so that last-minute changes (such as changing a “withheld” privileged document to a “redacted” privileged document) can be done much more quickly. The proper approach to tiffing, therefore, depends on the cost structure and privilege volume of each case, and there is not a one-size-fits-all approach.

2. Conclusion

Lawyers are trained to be generalists for the simple reason that, fundamentally, every case really is different. But when it comes to a large-scale document review, the model of a generalist practitioner working in a silo is not an efficient one. Rather, large-scale document reviews should be modeled on assembly lines, and this article has offered one workflow for such a model. The mark of a great eDiscovery attorney is to tailor the model above into an efficient workflow that makes sense for each particular case, based on, (yes) the generalist’s ability to analyze complex facts, consider substantive and procedural rules, serve clients’ business objectives, and develop and execute on a strategy—all at the time same.