PRODUCTION PITFALLS

A Production is an export of a piece of the review database, requested because it has been deemed relevant to the matter.

Well, that’s the easy answer.

The reality of production is more complicated — and is not an exact copy of the review database — but for sake of simplicity, that’s a suitable place to start. Because what we really want to discuss here is how to fundamentally understand the concept of production, and to explore how taking into account the interactions taking place within production can make light of this heavy topic.

There are three fundamental components interacting during a production to create the final deliverable: the document data fields, the review inputs fields, and the ESI Protocol. The goal of this post will be to analyze how simplifying these three components in a way to reduce errors during production.

The review database is built upon the document data and the reviewer input on that data, all of which is stored in fields. The ESI Protocol is doing nothing more than informing how that document data is to be handled during export. It identifies which fields (both document and input) should be exported and in what form. At no point is the interaction of these three components complex — it’s the activity around each component that makes it convoluted.

Briefly, here are the convoluting culprits for each piece:

• Document Data: poor handling of the data during and after processing can lead to complications that may not be immediately obvious but will come back to haunt a matter come time to produce. Examples include: inconsistency of deduplication strategy, incorrectly assigned time zones, and incorrectly assigned custodian values. All of these can technically be fixed, but as my evidence-based management professor repeatedly said, “You can’t fix what you f*** up in the first place”. which is why I want to reiterate it can technically be fixed but every one of those fixes opens up a new opportunity for error that you may not be as lucky to catch. To avoid this error trap, create standards that are then templatized so that the handling remains consistent throughout the case.
• Reviewer Input: the purpose of these fields is to communicate the reviewer’s interpretation of the document’s relevance to the case, and the more complicated this communication becomes the more likely an issue is to arise. I started my tenure in eDiscovery in an enormous multi-matter project that had more review fields than you could count and quality control checks on those review fields that could become so convoluted that even the seasoned vets’ heads would start to spin. Some reviews are going to be more complicated than others, that’s inevitable. However, the simpler the setup, the clearer the communication. When setting up your review, always be asking yourself, “Do I need this field and/or can I combine the goal of this field with another?” The fewer the fields the simpler the communication and the less likely a miscommunication is going to occur.
• ESI Protocol: different matters are going to require different specs, but there is a difference between a ‘need’, a ‘nice to have’, and a ‘just to have’. If your review database has both date and time in a single field and your ESI protocol has them split into two separate fields, is there a specific reason for that? Following that spec requires a manipulation which leads to an opportunity for error and it’s very possible that opposition is going to manipulate those separate fields back into a single field. Considering productions are regularly under a tight deadline, do you want to add an unnecessary manipulation that will occupy valuable time, when a necessary modifier like scrubbing privilege metadata may suffer as a result? Prioritize the needs, tolerate the nice to haves only after pushing back, and don’t allow the ‘just to haves’.

Productions fall along the entire spectrum of simple to complex. At times a difficult to execute production is inevitable, but other times the perceived difficulty is in fact a result of not taking into account the interactions that led up to the deliverable.

Design your ESI protocol to be as close to your database as possible, keep your review as simple as possible, maintain consistency in your processing practices, and your productions will become easier. And well, here at Easy Company, we really believe in Easy.