Close
Enter your
text here

Electronic Discovery

How Much Will it Cost? – eDiscovery Best Practices

By far, the most important (and, therefore, the most asked) question asked of eDiscovery providers is “How much will it cost?”.  Actually, you should be asking a few questions to get that answer – if they are the right questions, you can actually get the answer you seek.

With these questions, you can hopefully prevent surprises and predict and control costs:

  • What is the Unit Price for Each Service?: It’s important to make sure that you have a clear understanding of every unit price the eDiscovery provider includes in an estimate.  Some services may be charged per-page or per-document, while others may be charged per gigabyte, and others may be charged on an hourly basis.  It’s important to understand how each service is being charged and ensure that the price model makes sense.
  • Are the Gigabytes Counted as Original or Expanded Gigabytes?: For the per gigabyte services, it’s also important to make sure that you whether they are billed on the original GBs or the expanded GBs.  Expanded GBs can be two to three times as large (or more) as the original GBs.  Some services are typically billed on the original GBs (or at least the unzipped GBs) while others are typically billed on the expanded GBs.  It’s important to know which metric is used; otherwise, your ESI collection may be larger than you think and you may be in for a surprise when the bill comes.
  • Will I Get an Estimate in Advance for Hourly Billed Services?: When you ask for specific hourly billed services from the provider (such as professional consulting or technician services) to complete a specific task, it’s important to get an estimate to complete that task as well as advanced notification if the task will require more time than estimated.
  • What Incidental Costs are Billed?: It’s not uncommon (or unreasonable) for incidentals like project management, supplies and shipping to be included in invoices.  In particular, project management services can be an important component to the services provided by the eDiscovery provider.  But, the rates charged for these incidentals can vary widely.  Understanding what incidentals are being billed and the rates for those services is important to controlling costs.
  • If Prices are Subject to Change, What is the Policy for Those Changes and Notification of Clients?: Let’s face it, prices do change, even in the eDiscovery industry.  In ongoing contracts, most eDiscovery providers will retain the right to change prices to reflect the cost of doing business (whether they exercise those rights or not).  It’s important to know the terms that your provider has set for the ability to change prices, what the notification policy is for those price changes and what your options are if the provider exercises that right.

With the right questions and a good understanding of your project parameters, you can get to the answer to that elusive question “How much will it cost?”.

So, what do you think?  How do you manage costs with your eDiscovery providers?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Though it was “Switching Horses in Midstream”, Court Approves Plaintiff’s Predictive Coding Plan – eDiscovery Case Law

In Bridgestone Americas Inc. v. Int’l Bus. Mach. Corp., No. 3:13-1196 (M.D. Tenn. July 22, 2014), Tennessee Magistrate Judge Joe B. Brown, acknowledging that he was “allowing Plaintiff to switch horses in midstream”, nonetheless ruled that that the plaintiff could use predictive coding to search documents for discovery, even though keyword search had already been performed.

In this case where the plaintiff sued the defendant for a $75 million computer system that it claimed threw its “entire business operation into chaos”, the plaintiff requested that the court allow the use of predictive coding in reviewing over two million documents.  The defendant objected, noting that the request was an unwarranted change to the original case management order that did not include predictive coding, and that it would be unfair to use predictive coding after an initial screening had been done with keyword search terms.

Judge Brown conducted a lengthy telephone conference with the parties on June 25 and, began the analysis in his order by observing that “[p]redictive coding is a rapidly developing field in which the Sedona Conference has devoted a good deal of time and effort to, and has provided various best practices suggestions”, also noting that “Magistrate Judge Peck has written an excellent article on the subject and has issued opinions concerning predictive coding.”  “In the final analysis”, Judge Brown continued, “the uses of predictive coding is a judgment call, hopefully keeping in mind the exhortation of Rule 26 that discovery be tailored by the court to be as efficient and cost-effective as possible.”

As a result, noting that “we are talking about millions of documents to be reviewed with costs likewise in the millions”, Judge Brown permitted the plaintiff “to use predictive coding on the documents that they have presently identified, based on the search terms Defendant provided.”  Judge Brown acknowledged that he was “allowing Plaintiff to switch horses in midstream”, so “openness and transparency in what Plaintiff is doing will be of critical importance.”

This case has similar circumstances to Progressive Cas. Ins. Co. v. Delaney, where that plaintiff also desired to shift from the agreed upon discovery methodology for privilege review to a predictive coding methodology.  However, in that case, the plaintiff did not consult with either the court or the requesting party regarding their intentions to change review methodology and the plaintiff’s lack of transparency and lack of cooperation resulted in the plaintiff being ordered to produce documents according to the agreed upon methodology.  It pays to cooperate!

So, what do you think?  Should the plaintiff have been allowed to shift from the agreed upon methodology or did the volume of the collection warrant the switch?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

An Insufficient Password Will Leave You Exposed – eDiscovery Best Practices

In the first year of our blog (which now has over 1,000 posts!), we published a post regarding the importance of a strong password.  Given recent events with the Home Depot data breach and several celebrities’ accounts being hacked on Apple’s iCloud, it seems timely to revisit and update the topic.

As a cloud software provider, we at CloudNine Discovery place a premium on the security of our clients’ data.  For example, the servers hosting data for our OnDemand® platform are housed in a secured, SAS 70 Type II certified Tier 4 Data Center in Houston (which is where our headquarters is).  The security at this data center is military grade: 24 x 7 x 365 onsite security guards, video surveillance, biometric and card key security required just to get into the building.  Not to mention a building that features concrete bollards, steel lined walls, bulletproof glass, and barbed wire fencing.

Pretty secure, huh?  However, no matter how secure a system is, whether it’s local to your office or stored in the “cloud”, an insufficient password that can be easily guessed can allow hackers to get in and steal your data.  Some dos and don’ts:

Dos:

  • If you need to write passwords down, write them down without the corresponding user IDs and keep the passwords with important documents like your passport, social security card and other important documents you’re unlikely to lose.  Or, better yet, use a password management application that encrypts and stores all of your passwords.
  • Mnemonics make great passwords.  For example, “I work for CloudNine Discovery in Houston, Texas!” could become a password like “iw4C9diht!”. (by the way, that’s not a password for any of my accounts, so don’t even try)  😉
  • Change passwords every few months.  Some systems require this anyway.  You should also change passwords immediately if your laptop (or other device that might contain password info) is stolen.

Don’ts:

  • Don’t use the same password for multiple accounts, especially if they have sensitive data such as bank account or credit card information.
  • Don’t email passwords to yourself – if someone is able to hack into your email, then they have access to those accounts as well.
  • Personal information may be easy to remember, but it can also be easily guessed, so avoid using things like your kids’ names, birthday or other information that can be guessed by someone who knows you.
  • As much as possible, avoid logging into sensitive accounts when using public Wi-Fi as it is much easier for hackers to tap into what you’re doing in those environments.  Checking your bank balance while having a latte at Starbucks is not the best time.

The best and most difficult passwords to hack generally have the following components – many systems, including OnDemand (we require at least three of these) – require one or more of these:

  • Length: Good passwords are at least eight characters in length.  Longer passwords may be more difficult to enter, but you get used to entering them quickly,
  • Upper and Lower Case: Include at least one upper case and one lower case character.  For best results, don’t capitalize the first character (harder to guess),
  • Number: Include at least one number.  If you want to be clever, “1’ is a good substitute for “i”, “5” for “s”, “4” for “for”, etc.
  • Special Character: Also, include at least one special character, for best results, not at the beginning or end of the password.

When you follow the best practices above, your password should be much more difficult to hack, keeping you from feeling “exposed”.

So, what do you think?  How secure are your passwords?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – How Databases Were Built, Circa Early 1980s, Part 3

In the last couple of Throwback Thursday posts we covered the first stages in a database-building project (circa 1980), including designing and planning a database, preparing for a project, establishing an archive, coding and qc, and production status record keeping. The next steps are described here.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here, here and here.

Batching and Keying: After coding and quality control, the next step was batching the coding forms. An archive librarian removed completed coding forms from folders, ‘batched them into groups, updated the activity log, and packaged the forms for shipping.  The packaged forms were shipped off to a keypunch vendor – usually located outside of the U.S.  The vendor I worked for used a keying company located in Jamaica. The vendor keyed the information from the forms to magnetic computer tapes (see the image above). Those tapes and the coding forms were then shipped back to the coding vendor.  Depending on the size of the batch, keying could take days.  And there was shipping time on each end.  It could take a week or more to get data back for large batches.

Data Loading:  As I mentioned in an earlier post, for the most part, databases ‘lived’ on a vendor’s mainframe computer and were accessed by clients using computer terminals.  When the vendor received tapes from a keypunch vendor, the next step was loading to its mainframe computer.

End-User Training:  While this still happens today, training was a much bigger deal back in the day.  The normal business person was not computer literate – most of our clients had never used a computer before.  Training usually took a day or two, and it involved educating users on how to do searches, on how databases were structured, and on how data was coded in a specific database.

A word on schedules:  Today we live in a world where everything is done almost immediately.  Once documents are collected, processed and loaded (all of which can happen pretty quickly), documents are available for searching.  With initial databases, it usually took months before the first documents were available for searching.  Every step in the process (photocopying, archive establishment, coding, qc, batching, and keying ) took days or weeks.  Of course we didn’t wait for a step to be completed for all the documents before starting the next step, but even so, it was a long time before the first documents were available for searching.

A word on backups:  In the electronic world we live in today, we rely on computer backups…  and we do them frequently.  Even if there’s a significant technical problem, we can usually go to a fairly recent backup without too much work being lost.  This was always a concern with initial database projects.  Our law firm clients usually didn’t send us the ‘original working copy’ of a document collection.  They had a second copy made for the database work.  But a lot of work was done and a lot of time elapsed between delivery of those documents and data being available in the database.  Problems like fire, flooding, and packages lost in shipping could mean lost work.  And those things happened on occasion.

In next week’s post, we’ll take a look at how databases were used, and how searching and document retrieval worked.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Our 1,000th Post! – eDiscovery Milestones

When we launched nearly four years ago on September 20, 2010, our goal was to be a daily resource for eDiscovery news and analysis.  Now, after doing so each business day (except for one), I’m happy to announce that today is our 1,000th post on eDiscovery Daily!

We’ve covered the gamut in eDiscovery, from case law to industry trends to best practices.  Here are some of the categories that we’ve covered and the number of posts (to date) for each:

We’ve also covered every phase of the EDRM (177) life cycle, including:

Every post we have published is still available on the site for your reference, which has made eDiscovery Daily into quite a knowledgebase!  We’re quite proud of that.

Comparing our first three months of existence to now, we have seen traffic on our site grow an amazing 474%!  Our subscriber base has more than tripled in the last three years!  We want to take this time to thank you, our readers and subcribers, for making that happen.  Thanks for making the eDiscoveryDaily blog a regular resource for your eDiscovery news and analysis!  We really appreciate the support!

We also want to thank the blogs and publications that have linked to our posts and raised our public awareness, including Pinhawk, Ride the Lightning, Litigation Support Guru, Complex Discovery, Bryan University, The Electronic Discovery Reading Room, Litigation Support Today, Alltop, ABA Journal, Litigation Support Blog.com, InfoGovernance Engagement Area, EDD Blog Online, eDiscovery Journal, e-Discovery Team ® and any other publication that has picked up at least one of our posts for reference (sorry if I missed any!).  We really appreciate it!

I also want to extend a special thanks to Jane Gennarelli, who has provided some serial topics, ranging from project management to coordinating review teams to what litigation support and discovery used to be like back in the 80’s (to which some of us “old timers” can relate).  Her contributions are always well received and appreciated by the readers – and also especially by me, since I get a day off!

We always end each post with a request: “Please share any comments you might have or if you’d like to know more about a particular topic.”  And, we mean it.  We want to cover the topics you want to hear about, so please let us know.

Tomorrow, we’ll be back with a new, original post.  In the meantime, feel free to click on any of the links above and peruse some of our 999 previous posts.  Now is your chance to catch up!  😉

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Court Refuses to Ban Samsung from Selling Products Found to Have Infringed on Apple Products – eDiscovery Case Law

Apple may have won several battles with Samsung, including ultimately being awarded over $1 billion in verdicts, as well as a $2 million sanction for the inadvertent disclosure of its outside counsel firm (Quinn Emanuel Urquhart & Sullivan LLP) commonly known as “patentgate”.  But, Samsung has may have won the war with the court’s refusal to ban Samsung from selling products that were found to have infringed on Apple products.

Last Wednesday, U.S. District Judge Lucy H. Koh refused to permanently ban Samsung from selling several mobile phones and tablets that a jury found infringed on Apple patents, ruling Apple hadn’t shown that it would suffer irreparable harm to its reputation.  In her order, Judge Koh stated that the plaintiff hadn’t provided sufficient evidence that it will suffer lost sales specifically due to Samsung’s infringement of the three patents at issue, nor had it demonstrated that the patented inventions drive consumer demand for Samsung’s infringing products.

In its motion for a permanent injunction, Apple had argued that the nearly $120 million in damages that was awarded in May wasn’t enough to compensate Apple for the harm caused by Samsung’s infringement. Apple stated that the ban was necessary to separate Apple’s reputation as an “amazingly innovative company” from Samsung’s reputation as a “fast follower.”

Apple argued that trial evidence demonstrated a causal nexus between the alleged sales-based harm and Samsung’s infringing behavior, but argued, however, that when reputational harm is alleged, the second prong of the irreparable harm test falls away and no separate proof of causal nexus is required.  However, Judge Koh found “no reason to depart from the Federal Circuit’s guidance that a patentee must demonstrate a causal nexus between infringement and any alleged irreparable harm – including injury to reputation.”  She also noted that “Samsung argues persuasively that Apple’s reputation has proved extremely robust … weakening Apple’s claim that it has suffered or will suffer irreparable harm to its reputation from infringement of only three patents.”

So, what do you think?  Will the Apple-Samsung litigation ever end?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Court Sides with Defendant in Dispute over Predictive Coding that Plaintiff Requested – eDiscovery Case Law

In the case In re Bridgepoint Educ., Inc., Securities Litigation, 12cv1737 JM (JLB) (S.D. Cal. Aug. 6, 2014), California Magistrate Judge Jill L. Burkhardt ruled that expanding the scope of discovery by nine months was unduly burdensome, despite the plaintiff’s request for the defendant to use predictive coding to fulfill its discovery obligation and also approved the defendants’ method of using search terms to identify responsive documents for the already reviewed three individual defendants, directing the parties to meet and confer regarding the additional search terms the plaintiffs requested.

In this case involving several discovery disputes, a telephonic discovery conference was held in the instant action on June 27, during which, the Court issued oral orders on three of four discovery disputes.  As to the remaining dispute, the Court requested supplemental briefings from both parties and issued a ruling in this order, along with formalizing the remaining orders.

The unresolved discovery dispute concerned the plaintiffs’ “request for discovery extending beyond the time frame that Defendants have agreed to” for an additional nine months.  In their briefing, the defendants (based on the production efforts to date) claimed that expanding the scope of discovery by nine months would increase their review costs by 26% or $390,000.  The plaintiffs’ reply brief argued that the defendants’ estimate reflected the cost of manual review rather than the predictive coding system that the defendants would use – according to the plaintiffs, the cost of predictive coding was the only cost relevant to the defendants’ burden, estimating the additional burden to be roughly $11,279.

Per the Court’s request, the defendants submitted a reply brief addressing the arguments raised by the plaintiffs, arguing that predictive coding software “does not make manual review for relevance merely elective”.  The defendants argued that the software only assigns a percentage estimate to each document that reflects the assessment of the probability that the document is relevant, but the software is not foolproof and that attorney review is still required to ensure that the documents produced are both relevant and not privileged.

Judge Burkhardt, citing the “proportionality” rule of Federal Rule of Civil Procedure Rule 26(b)(2)(C), denied expanding the scope of discovery by nine months, finding that “Defendants have set forth sufficient evidence to conclude that the additional production would be unduly burdensome”.

The plaintiffs, claiming that the defendants “unilaterally-selected search terms” to identify the original production, also argued discovery produced from three Individual Defendants should be added to the Defendants’ predictive coding software.  But, Judge Burkhardt, formalizing the oral order, stated “[t]he Court approved Defendants’ method of using linear screening with the aid of search terms to identify responsive documents with regard to the emails already reviewed for the three Individual Defendants. The parties were directed to meet and confer regarding the additional search terms Plaintiffs would like Defendants to use.”

So, what do you think?  Was the additional discovery scope unduly burdensome or did the plaintiff have a point about reduced discovery costs?  Please share any comments you might have or if you’d like to know more about a particular topic.

eDiscovery Daily will resume posts on Tuesday.  Happy Labor Day!

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Blog Throwback Thursdays – How Databases Were Built, Circa Early 1980s, Part 2

The Throwback Thursday blog two weeks ago included discussion of the first stages in a database-building project (circa 1980), including designing and planning a database, and preparing for a project. The next steps are described here.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here and here.

Establishing an Archive: Litigation teams shipped paper documents to be coded to a service provider, and the service provider’s first step was ‘logging documents in’ and establishing a project archive. Pages were numbered (if that hadn’t already been done) and put into sequentially numbered file folders, each bearing a label with the document number range.  Those files were placed into boxes, which were also sequentially numbered, each of which had a big label on the front with the range of inclusive files, and the range of inclusive document numbers.

Logs were created that were used to track a folder’s progress through the project (those logs also meant we could locate any document at any time, because the log told us where the document was at any point in time).  Here are sample log entries for a few folders of documents:

Note, this sample is a little misleading:  logs were filled in by hand, by an archive librarian.

Coding and QC: Folders of documents were distributed to ‘coders’ who recorded information for each document – using a pencil and paper coding form that had pre-printed field names and spaces for recording information by hand.  When a coder finished coding all the documents in a folder, the coding forms were put in the front of the folder, the folder was turned back into the archive, and the next folder was checked out.  The same process was used for qc (quality control) – the documents and coding forms were reviewed by a second person to ensure that the coding was correct and that nothing was missed.

As project managers, we kept very detailed records on progress so that we could monitor where things stood with regard to schedule and budget.  At the end of every workday, each coder and qcer recorded the number of hours worked that day and the number of documents and pages completed in that day.  An archive librarian compiled these statistics for the entire coding and qc staff, and on a daily basis we calculated the group’s coding and qc rates and looked at documents / pages completed and remaining so that we could make adjustments if we were getting off schedule.

In next week’s post, we’ll look at the next steps in a database-building project.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

When Reviewing and Producing Documents, Don’t Forget the “Mother and Child Reunion” – eDiscovery Best Practices

I love Paul Simon’s music.  One of my favorite songs of his is Mother and Child Reunion.  Of course, I’m such an eDiscovery nerd that every time I think of that song, I think of keeping email and attachment families together.  If you don’t remember the Mother and Child Reunion, you might provide an incomplete production to opposing counsel.

BTW, here’s a little known fact: Paul Simon took the title of the song Mother and Child Reunion from the name of a chicken-and-egg dish he noticed on a Chinese restaurant’s menu.

Like the rest of us, attorneys don’t like to feel shortchanged, especially in discovery.  While there are exceptions, in most cases these days when an email or attachment is deemed to be responsive, the receiving party expects to also receive any “family” members of the responsive file.  Attorneys like to have the complete family when reviewing the production from the other side, even if some of the individual files aren’t responsive themselves.  Receiving an email without its corresponding attachments or receiving some, but not all, of the attachments to an email tends to raise suspicions.  Most attorneys don’t want to give opposing counsel a reason to be suspicious of their production, so parties typically agree to produce the entire email “family” in these cases.  Here’s a scenario:

The case involves a dispute over negotiated gas rate agreements between energy companies and Federal Energy Regulatory Commission (FERC) approval of those rate agreements.  A supervisor at the company verbally requests a copy of a key contract from one of his employees, along with the latest FERC filings and the employee emails a copy of the contract and FERC filing summary attached to an email with the subject “Requested files” and the body stating “Here you go…” (or something to that effect).  A search for “negotiated w/2 (gas or rate or agreement)” retrieves the contract attachment, but not the email, which doesn’t really have any pertinent information on it, or the FERC filing summary.  Only part of the email “family” is responsive to the search.

If it’s important to produce all communications between parties at the company regarding negotiated gas agreements, this communication could be missed – unless your review protocol includes capturing the family members of responsive files and your review software provides an option to view the family members of responsive files and include them in search results.  I underlined “option” because there are still a few cases where parties agree to limit production to actual responsive files and not produce the families (though, in my recent experience, those cases are exceptions).

If your case isn’t one of the exceptions, make sure you have a well thought out protocol and robust software for including family members in your search results and in your document reviews for responsiveness, as well as automated and manual Quality Assurance (QA) and Quality Control (QC) checks to ensure your production contains complete family groups.

So, what came first, the chicken or the egg?  It doesn’t matter, as long as the family group is intact.  🙂

So, what do you think?  How do you handle family groups in discovery?  Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

Browning Marean: 1942 – 2014
 

Browning Marean passed away this past Friday (August 22) at the age of 71 from complications after a several months battle with esophageal cancer.  As described in several wonderful tributes that I read today, his death was not only a huge loss to the eDiscovery and legal technology community, but to any individuals that had the opportunity to know him and work with him.  Here are links to those tributes, I encourage you to take some time out today and get to know him through the eyes of others like I did today.

Links:

There are probably others that I missed – feel free to share with our readers if you know of other tributes.

Also, here is a link to a video of Browning as eDiscovery Board Member of Bryan University.  His love of technology, his belief that eDiscovery is here to stay and his belief in the importance of strong project management skills is evident in his comments.  Rest in Peace, Browning.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.