Showing posts with label discovery. Show all posts
Showing posts with label discovery. Show all posts

Thursday, March 22, 2012

Why Paper Is A Way of The Past...

Let me preface this by saying the following - Everyone of my constituents know that paper discovery has seen its day. However, I still routinely get pulled into discovery matters where paper was looked at as the best approach.

Though most of my client related material is on the computer, I still seem to wind up with lots of paper on all my projects. That is in part because some things are just easier to read or manage in paper. I have always been a more visual person and worked better with paper. Some (my parents) would probably blame that on some random learning disability I supposedly had which was the reason I ranked near the bottom of every class. So, for me, paper is the way to go - no matter the reason.

In the context of litigation discovery, however, the times they are a changing. In one of his decisions from a few years ago, Judge Waxse of the District of Kansas addressed the question of whether paper is a “reasonably usable format” in which to produce ESI, at least under the circumstances of that case. White v. Graceland Coll. for Lifelong Learning, Inc., 2008 WL 3271924 (D. Kan. Aug. 7, 2008), is a wrongful termination case in which the defendant produced e-mails and attachments in paper. Cn you say "archaic?" I thought you could. A paralegal converted the native documents to PDF, printed and produced them. The plaintiff moved to compel production of the records in their native format, arguing that he could not otherwise determine when particular records were created or sent, or whether the records had been modified. Judge Waxse agreed, finding that the defendant “failed to produce the emails and attachments in either the form in which they are ordinarily maintained, or in a ‘reasonably usable form,’ as required by Rule 34(b)(2)(E)(ii).”

Clearly, the e-mails and attachments in this case were not produced “in the form in which they [were] ordinarily maintained in the normal course of business,” which is nearly always native. So, the question became whether simple paper printouts of the records were a “reasonably usable form.” Quoting the Federal Advisory Committee’s notes to the recently amended Rule 34, he emphasized that the producing party’s “option to produce in a reasonably usable form does not mean that a responding party is free to convert electronically stored information from the form in which it is ordinarily maintained {in the normal course of business} to a different form that makes it more difficult or burdensome for the requesting party to use the information efficiently in the litigation.” Moreover, where “the responding party ordinarily maintains the information it is producing in a way that makes it searchable by electronic means, the information should not be produced in a form that removes or significantly degrades this feature.” Ultimately, Judge Waxse held that, paper was not a “reasonably usable” substitute for the native format records.

Now, I don’t think Judge Waxse is suggesting in this opinion that paper is never a reasonably usable form of production. But maybe he should have suggested just that. Many times, I hear clients and opposing parties discuss formats which are more difficult to deal with than the usual email or Word document. I agree that there are plenty of "challenging" file types to deal with including but not limited to CAD drawings, proprietary systems, etc. But technology has come along way since Judge Waxse's decision. Now there is a viewer for nearly everything out there. But I don’t think that Judge Waxse is suggesting that native format will always be required.  What the case does highlight, however, is the importance of thinking ahead about the form of production, and selecting a production format that will meet the reasonable needs of the requesting party. This requires that a party understand its own electronically stored information as well as the issues in the case, so that critical features can be incorporated into the production format. This point is where data mapping becomes so critically important. More and more corporations are realizing the extreme challenge they face because they don't have a data map. Perhaps the best lesson from White is one that seems to be a refrain in an increasing number of opinions on e-discovery: “The Court notes that this discovery dispute is an example of one which … could have been altogether avoided had the parties adequately conferred at their Fed.R.Civ.P. 26(f) conference[.]” Coming to the discovery conference prepared to talk about important issues such as production format, with a reasonable proposal that will adequately meet the opposing party’s legitimate needs, may save a great deal in legal fees and avoid some unfavorable outcomes once the issue is before the court. And a great rule of thumb is that whoever shows up at the meet and confer most prepared, will almost always get what they want. Just ask, Judge Peck.

Wednesday, February 29, 2012

How You Turn All That E-Discovery Work Into An Asset

Spoiler Alert! This isn't another blog about predictive coding. Sorry if the "flavor of the month" discussion was what you were craving.

I spoke briefly in my last blog about how the 'secret is in the dirt'. It is a term Ben Hogan used many years ago when discussing practicing golf. The point he was trying to make was that if you make a repeatable swing (or process) and practice it every time then that will lead to success on the golf course. So the more you practice and fine tune the swing based on previous feedback and make it into a repeatable process then the more success you will have. How do we translate that to e-discovery?

I am sure many of you see where I am going with this blog entry but wait just a second.

Many times, I have clients who once the litigation has been served immediately (or not so immediately) start down the path of what I like to call the traditional e-discovery workflow. The client (with or without assistance) has usually already begun the task of identifying potential relevant custodians during their legal hold process. And maybe even taking it one step further and identifying some data sources. The process of identifying data sources is a common first step which has been memorialized in the often overused EDRM model.

But let's take one step back. How did we get to the identification of those custodians and data sources? As one GC told me, "I feel like I start over every time I get a new case in the door. It is costing me millions I am sure." Generally, the lawyers get together with the appropriate business people and discuss who is involved from every level. That conversation usually leads (or should lead) to what data sources should be included outside of the custodial data. This conversation usually grows and grows and can go down many different routes leading to some sort of multi-version document that attempts to outline the inevitable data collection process. We are all more than familiar with this process. We are also more then familiar with how this process takes on a life of its own and changes more times than a Miss USA contestant changes outfits in ninety minutes.

But what if based on the profile of a litigation matter, you could already know the answers to these questions? Or at least had a really good idea of where to start?

The answers are in the litigation of the past and present. If corporations were take the data that is produced in the standard workflow process and build a knowledge base, then the sky is the limit. This information that is gathered can be used to determine the custodians that commonly occur in certain litigation. Your risk management team could look into litigation "triggers" - what events occur that trigger litigation inside the corporation. Human resources could look into issues related to labor and employment based on reporting from your corporations ediscovery knowledge base.

The building of the knowledge base is just like the building of any other database of information. And I will discuss in my next entry how we avoid the age old issue of bad data and build an effective knowledge base.