D4 Announces eNtrustTM – One of the first Managed Services Solutions for litigation support.
eNtrustTM combines the latest hardware, software and people into a custom offering that meets your organization’s specific set of discovery needs.
Designed to give legal departments in-house eDiscovery capabilities that are scalable for virtually all legal matters, eNtrustTM provides a highly responsive streamlined process that delivers substantial and predictable cost savings where flexibility is key.
In This Issue
- eDiscovery: In-House, In Order – Whitepaper by Chuck Kellner
- Tips & Tricks: Database Discovery – by Peter Coons
- eDiscovery In the News & On the Web
- Upcoming Events and Webinars with D4, LLC
Written by Chuck Kellner, SVP at D4 and eDiscovery Expert
There is no one-size-fits-all eDiscovery solution. Here is a blueprint to specify and build a right-sized, in-house litigation support capability that is both cost-effective and measurable against other organizational goals.
Bringing eDiscovery in house is a hot topic. Legal departments are investigating and investing in capabilities to become more self-sufficient with more aspects of the EDRM. With rising costs of litigation discovery and with increasing pressure on law department budgets, so the discussions go, it makes sense to be self-sufficient in managing electronic discovery than to rely on outside counsel or the litigation support community to provide the services.
Return on Investment
But where do the savings come from? Is it clearly the case that an organization will save money or gain some other benefit by bringing in software or services it previously contracted out? Is there a tradeoff in cost between developing the in-house capability, having an on-call outsourcing capability, or a hybrid solution?
What are the organizational goals apart from cost? Are there collateral evaluations to make about effective dispute resolution, true early case assessment, impact on co-lawyering with outside counsel, intrusion on business cllients, availability and consistency of internal IT and litigation support staffing, and procurement and maintenance of infrastructure?
How does the effort fit with IT strategic planning? If you buy into a solution does it fit with what the rest of the organization is planning? Can you easily opt in later on to new technologies or capabilities? Is corporate IT planning any major changes that will benefit the litigation support effort? For example, are there plans for single-instance email archiving or document management systems? Do litigation or compliance needs drive these efforts? Are the roadmaps for these initiatives short enough to deliver value to the law department, or should the litigation support effort fend for itself for at least the critical near future?
Can in-house eDiscovery yield a tactical advantage? Minimizing vulnerabilities make the organization a smaller target. Ideally, the efficiency of having in-house, in order, litigations will be easier to resolve, or even less likely. Ideally, the capability that you build or buy fits the current and foreseeable docket and caseload.
Clearly, no one size fits all.
No single RFP process or software solution will answer these questions. The right-sized effort begs a detailed internal assessment and an ordering of priorities against budget. Solutions getting the final nod should be capable, flexible, scalable and cost-effective. This paper is a blueprint to specify and build a right-sized in-house litigation support capability that is both cost-effective and measurable against other organizational goals.
Database Discovery – Written by Peter Coons, SVP at D4 and Digital Forensics Expert
Frequently in the discovery process databases contain potentially relevant information or records that must be provided to opposing counsel. Rule 34(a)(1)(A) states that a party may request (within scope), “any designated documents or electronically stored information — including writings, drawings, graphs, charts, photographs, sound recordings, images, and other data or data compilations — stored in any medium from which information can be obtained either directly or, if necessary, after translation by the responding party into a reasonably usable form. ” The last part is highlighted for a reason, but before we discuss let’s look at a 200,000 foot view of a database.
What’s a database? Yes, you have heard the word before, but do you really understand what a database is, or does?
Think of an Excel spreadsheet. Now think about that spreadsheet with three columns. The first column is NAME, the second is ADDRESS, and the third is PHONE NUMBER. You are planning a party and need to make a guest list so you fill in the spreadsheet. Voila, you have just created a database.
Now in your mind add a fourth column called RSVP and there are three possible entries: YES, NO, or MAYBE. However, you don’t use the words themselves, you use a coded system of 1, 2, and 3, respectively. How do you know what that code means if you are not familiar with our pretend database? You don’t because that information is another database, or more accurately, a table. So now we have a database that comprises two tables. In non-make believe database land, databases usually have dozens, and sometimes hundreds of tables. And each table has dozens, or hundreds of fields. That’s why it’s important to get a “data dictionary” from the other side or find out how the database works from the database administrator.
We have now just built a relational database or more accurately, a hierarchical database.
So what does this mean for discovery? Well, let’s say you are interested in finding out who attended the party, or those that responded that they would attend. If you ask the other side for the entire database it might not be possible for you to determine that information without a thorough understanding of the database and how the fields within various tables relate to one another. It certainly wouldn’t help you if they handed you over the RSVP Table by itself. Nor would it be helpful if you just had the Contact Table.
What would be helpful is to have a report with NAME, maybe the contact info, and the RSVP status in plain English, not code. Like this…
This information would most likely be the most useful as an electronic file so it can be searched. What kind of an electronic file? Usually what’s called a CSV file, or comma delimited file, will suffice. That’s a fancy word for a text file with some markers (comma) that identify where fields (Name, Address, Phone) start and end.
Is it OK to deliver the contents of the database as a CSV file? Now go back to the first paragraph: “if necessary, after translation by the responding party into a reasonably usable form”. So, the answer is YES and maybe NO. Yes, it is fine if it has been discussed with the other side and they understand why you are producing potentially relevant records in a technically non-native format. This is why the 26(f) conference exists. Raise the issue and make a proposal at that time, unless you plan on fighting production of the database. And NO because if you start producing data in a CSV file without informing the other side you can be sure you will get a phone call or e-mail.
Is database discovery always this easy? No. Hiring or consulting with a discovery expert on database issues can help. At the very least talk to the database administrator within the corporation to get the “down low on the DB”. It’s also important to know that production of data in a CSV or other format may not necessarily relieve one of the duty to preserve the database in its native format.
For more information regarding Database Discovery, contact Peter Coons.
Moving to the Cloud – the Users’ Perspectivet
by Ulrika Hedquis
“Fox Gaurding the Hen House”
Blog Post by Michael Arkfeld
AccessData Introduces the New “AD Triage”