Document Production — Look Before You Leap
You have filed a lawsuit and you are set for a “meet & greet” conference with opposing counsel(s) to review and agree on discovery.
What should you expect from opposing counsel and their client(s)?
The Federal Rules of Civil Procedure, of course, provide structure to this event and Rule 26 issues certain mandates on what the parties should discuss and that parties should arrive at the conference prepared and knowledgeable. Sadly, many states such as Florida are far behind the times in setting forth such a clear structure in the Rules of Civil Procedure. Florida does not even require any discovery conference similar to the “meet & greet” under the federal rules; at least until it is generally too late.
If everyone is acting in good faith, and depending on the case, defense counsel should arrive with basic knowledge of their client’s IT structure, including:
- Who oversees IT and e-discovery at the client’s organization?
- Who has “hands-on” responsibilities for IT and e-discovery at the client’s organization?
- Has there been a legal hold implemented?
- What is the scope of the legal hold?
- Has a legal hold been placed on mobile, removable and personal devices, as well as desktop computers?
- What are the organization’s legal hold policies?
- Does the organization maintain a Data Map of it’s IT structure, including data storage locations?
- What technology, both hardware and software, does the organization use to support its various operations and departments, which may relate to the subject matter of the lawsuit?
- Does the organization use single sign-on technology for its systems?
- What database platform(s) does your organization use for enterprise archiving, records, and content management?
- What productivity software does the organization use?
- What collaboration tools are used in the organization?
- What software platforms are used for email in the organization?
- What social media platforms are used by the organization as a part of daily functions; whether published externally or internally?
- What data deletion policies has the organization followed in the past?
- What backup policies has the organization followed in the past?
- Has a data/document collection already begun, which may respond to the lawsuit?
- Has the process of culling data/documents been started?
The Collection or Culling process has started.
Be alert to this. If the methods and procedures to be used have not been mutually agreed, that means the process has begun with no mutual input, control or agreements. Some producing parties are encouraged to get the collection, culling and production process started and far down the line so they can argue that going back will be “burdensome and unduly expensive”. You have heard that more times than you can probably count.
This can also raise the issue of the format for discovery. Will the documents be produced as PDF’s? Will the documents be produced as TIFF’s? Will text files be produced with the document images? Will load files compatible with common document management software be included with the production? Will there be any need for native production?
I have seen many attorneys who request documents be produced in “native format” with “metadata intact” as a part of their boiler plate requests. That is, in my opinion, a mistake and ignores the specifics of each case. It is fair to request native format, including metadata for all “documents” in which versioning, commenting, interlineating, and collaboration tools were used. The obvious example is a PDF document in which users have used the sticky note or highlight text features. In that case those notes and other markups identify the author of the markup, and the date and time of the edit. If only an image is produced, you lose all that important information Word and other Microsoft Office products have a similar feature in the “Review” and “markup” functions. In these documents, it makes the most sense to produce the native files with the metadata to identify authors, dates and edits.
Problems with document production are often driven by form.
Fairly uniformly in both federal and state rules, if the requesting party does not specify the form of the production, the responding party may produce in any reasonable form or in a form reflective of the way the data/documents were kept in the normal course of business.
This is an area in which detail and specificity can be very important when you manage the ultimate document production.
The most common production form is TIFF (Tagged Image File Format) or PDF (Portable Document Format). Both formats have positives and negatives; often, you may be able to have them produced in both formats. Are TIFF and PDF searchable? Not necessarily. Both file formats require text files, typically created through a process called OCR (Optical Character Recognition). If either TIFF or PDF files are produced to you without text files, it is likely the images are just that – images, and they are not searchable.
Redactions, Bates© numbering and other labeling.
You will want to search for document identification numbers (Bates© numbering) in documents. You will also want to identify and sort on redacted documents.
If the documents produced are “full text searchable” that is easy – right? Not necessarily. If the producing party OCR’s the documents before they insert Bates© numbering and before they insert their “redacted” labels, neither the numbers or the existence of the redactions will be searchable, unless they re-OCR the entire collection.
Ask for the production so it makes sense for you.
The producing party is unlikely to suggest production forms or methods that will help or accommodate your ability to use and manage productions. So, ask.
Want TIFFs with text files; OCR after all page ID’s and redactions are made; all redactions bearing the term “redacted” in the areas applied; objective coding; and corresponding load files? Ask for them.
You may receive a response that the request is unreasonable, overly burdensome, yada, yada; but all these requests are reasonable with the possible exception of “objective coding”.
What is objective coding and why should the producing party provide it?
The answer to this question is multifaceted.
Objective coding are fields of information about the documents. Much like “metadata” these fields of information, on an objective coding basis, would provide information such as:
- Date of the document.
- Author of the document.
- Recipient(s) of the document.
- Copies and blind copy recipients.
- Type of document.
- Number of pages.
- Begin and end bates numbers.
Is it unduly burdensome? Possibly. Once, the only practical way to manage documents was to add this coding to the document database. Today, enhanced search and management software make it possible (if not wise) to do so without document coding.
But, ask. If the party producing the documents plans to have objective coding done, offer to apportion the cost with them to receive only the objective fields of coding as a part of the load files. They may agree with an offer to share (not split) the costs.
In my opinion, objective coding should be provided as a part of digital production, but I suspect few judges would agree (or possibly even understand) the reasoning.
Email is a different animal.
Production of email should be approached differently than most other documents and data. Email software, such as Outlook, ties certain data (metadata) directly to each email sent and received. This metadata or “header information” is essential to managing email production so it makes any sense.
What metadata are we talking about?
Here is small sample of the metadata contents of an Outlook mail header:
- CC, BCC and Forwards
- Date(s) sent, received and forwarded
- Time(s) sent, received and forwarded
- Software identification
- Server identification(s)
- Subject thread
- Email addresses
- Delivery status
- And even more.
Besides the obvious value of this information, having the header information, it will permit you to perform “threading” on the produced emails. If you have ever sorted your own emails based on “threads”, then you have seen the first email that may have started a series of replies. That is the thread. But, email threading can also allow you to associate forwarded and blind copied emails with the “beginning” email, copies and replies.
Besides all this wonderful stuff, email metadata allows you to manage the emails in terms of authors, dates and recipients by grouping them together. So, if I want to see all emails where “John Smith” is the author, I can group those altogether.
Any reason that asking for email header metadata is unreasonable, burdensome, etc? Nope; absolutely not; cannot think of a single reason why.
Spreadsheets, Power Points and Database files are also different animals.
If the producing party provides scanned images of spreadsheet documents, you lose the most valuable parts of the file; the ability to manipulate the data and the ability to see the formulas used in the spreadsheet. Always ask for spreadsheets to be produced as an image file placeholder and also produced as a native file with formulas intact.
Power Points are great to have, but what you really want is the thought process that as gone into the ultimate presentation. Always ask for Power Points in native format with the speaker notes intact.
Database files present special problems. Many businesses have created their own proprietary software for managing databases or have purchased expensive and special software for that purpose. This is an area that requires the parties to really work together. Can the database be exported as a tab or comma delimited file that might be accommodated in another database program such as Microsoft’s Access? Can the database software be purchased so the data is usable? Will the producing party provide a review environment?
Think before you ask for production.
The above is just a general thumbnail look at these subjects. If you do not know enough to be comfortable about these and other e Discovery subjects, find someone you trust or hire an expert. It is well worth the time and expense to think before you request.