If experience has taught us anything about Requests for Production it’s that we can predict with near-certainty what the response will be:

1. The definitions will draw boilerplate objections;
2. The individual requests will draw boilerplate objections;
3. The forms of production designated will draw objection and be more-or-less summarily ignored.  The responding party will produce any form you designate, so long as it’s TIFF.
4. The responding party’s counsel will then assure the court that, save for privileged matter, you’ll get everything in exactly the same form as the responding party’s counsel.  “What could be more just or equitable than that, Your Honor?”

The responding party’s response is a given; but, your request can be better crafted to expose the obstructive character of the response and make it easier for the Court to compel production.

The gross shortcomings in e-discovery are commonly dismissed by the inarguable observation that “no production is perfect.”  Granted, but how far short of perfect is sufficient?  Is “lousy” close enough?

“Lousy” is what requesting parties have been conditioned to accept, and a key enabler of same is the overreaching, shotgun nature of most requesting parties’ definitions and requests for production. Continue reading →

I speak with a lot of judges about e-discovery and digital evidence.  I’ve taught at Federal Judicial Center programs from coast-to-coast and addressed confabs of judges in various states. Some of these presentations have turned into annual pilgrimages.  Have PowerPoint.  Will travel.

It’s a privilege to address judges because, among their own, judges are more cordial, relaxed and candid than in their courtrooms.  But, it’s also a responsibility and a challenge.  In the state systems, I can often be a judge’s first exposure to e-discovery.

Lawyers want the quick course in e-discovery.  They expect to glean ESI skills in minutes, before they glaze over with the talk of metadata and forms of production. Lawyers seek the canned checklist or scripted list of questions, and little care if they understand what the check boxes mean or what the follow up question should be.

It drives me bonkers.

Judges want the quicker course in e-discovery.  They’re not driven to win the case. They’re not worried about losing a client or looking bad to the partners. They know that discovery rulings are discretionary and rarely prompt findings of reversible error.  Federal District Judges get to keep their jobs for life. Apart from hereditary monarchs, who else has that sort of job security?

Judges have hardly any incentive to learn something new, save one: They really want to make the right decisions.

But despite such purity of purpose, there are many reasons why e-discovery can be more challenging for the bench than for practicing attorneys, viz.:

• Judges tend to be more senior, with the consequence that most had little hands-on experience with electronically stored information (ESI) in their own law practices;
• Most lawyers are at sea with the technology, so less adept at framing ESI issues, making a record and educating courts;
• The common practice to “split the baby” to achieve a just result rarely prompts good outcomes in e-discovery.

Recently, a judge asked me to pull together tips for jurists dealing with e-discovery; a list slated to be part of a presentation to a statewide judicial conference later this year. Responding to that request became the topic of my upcoming column in the October issue of Law Technology News, where I offer ten tips for judges who want to get e-discovery right.  Some are merely aspirational.  Some are pretty specific.  Here’s  a preview: Continue reading →

I got a call from a lawyer I don’t know on Sunday evening.  He reported that he’d received production of ESI from a financial institution and spent the weekend going through it.  He’d found TIFF images of the pages of electronic documents, but couldn’t search them.  He also found a lot of “Notepad documents.”  He’d sought native production, so thought it odd that they produced so many pictures of documents and plain text files.

As it’s unlikely a bank would rely on Windows Notepad as its word processor, I probed further and learned that that the production included folders of TIFF images, folders of .TXT files (those “Notepad documents”) and folders of files with odd extensions like .DAT and .OPT.  My caller didn’t know what to do with these.

By now, you’ve doubtlessly figured out that my caller received an imaged production from an opponent who blew off his demand for native forms and simply printed to electronic paper.  The producing party expected the requesting party to buy or own an old-fashioned review tool capable of cobbling together page images with extracted text and metadata in load files.  Without such a tool, the production would be wholly unsearchable and largely unusable.  When my caller protests, the other side will tell him how all those other files represent the very great expense and trouble they’ve gone to in order to make the page images searchable, as if furnishing load files to add crude searchability to page images of inherently searchable electronic documents constitutes some great favor.

It brings to mind that classic Texas comeback, “Don’t piss in my boot and tell me it’s raining.”

It also reminds me that not everyone knows about load files, those unsung digital sherpas tasked to tote metadata and searchable text otherwise lost when ESI is converted to TIFF images.  Grasping the fundamentals of load files is important to fashioning a workable electronic production protocol, whether you’re dealing with TIFF images, native file formats or a mix of the two.  I’ve been wanting to write about load files for a long time, but avoided it because I just hate the damn things!  So, this post is a load (file) off my mind. Continue reading →

Recently, I’ve weighed in on disputes where the parties were fighting over whether the e-mail production was sufficiently “native” to comply with the court’s orders to produce natively.  In one matter, the question was whether Gmail could be produced in a native format, and in another, the parties were at odds about what forms are native to Microsoft Exchange e-mail.  In each instance, I saw two answers; the technically correct one and the helpful one. 

I am a vocal proponent of native production for e-discovery.  Native is complete.  Native is functional.  Native is inherently searchable.  Native costs less.  I’ve explored these advantages in other writings and will spare you that here.  But when I speak of “native” production in the context of databases, I am using a generic catchall term to describe electronic forms with superior functionality and completeness, notwithstanding the common need in e-discovery to produce less than all of a collection of ESI.

It’s a Database

When we deal with e-mail in e-discovery, we are usually dealing with database content.  Microsoft Exchange, an e-mail server application, is a database.  Microsoft Outlook, an e-mail client application, is a database.  Gmail, a SaaS webmail application, is a database.  Lotus Domino, Lotus Notes, Yahoo! Mail, Hotmail and Novell GroupWise—they’re all databases.  It’s important to understand this at the outset because if you think of e-mail as a collection of discrete objects (like paper letters in a manila folder), you’re going to have trouble understanding why defining the “native” form of production for e-mail isn’t as simple as many imagine.  Continue reading →