Migrated from eDJGroupInc.com. Author: Babs Deacon. Published: 2013-05-15 05:54:41Format, images and links may no longer function correctly. We have all experienced the eDiscovery “flavor of the month”. Right now, it’s predictive coding. Previously it was analytics and before that it was early case assessment (ECA). Buzz around a particular new kind of software, platform or method is great for the eDiscovery community because it gives everyone a reason to research and discuss newer methods at conferences and in the press and blogosphere. However, this kind of buzz can become a drag on the industry when it percolates into the software and service provider selection process in an uninformed way.
Plainly put, when clients demand that a provider offer a software functionality or service, without knowing enough about a feature or process to evaluate the provider’s competence in that area or even use the offering at all, it skews selections and forces vendors to offer products that they might not have otherwise provided. I liken it to buying a Porsche because it can go 200 MPH even though the traffic on the Garden State Parkway moves at a 45 MPH 95% of the time. I am a big fan of buying only what you can really use: case in point – my 2007 Mini CooperS “Nino Carino” With its manual transmission, it is very zippy and gets great gas mileage.
To put this in an eDiscovery context, I am reminded of the RFPs I have seen during my stints at two eDiscovery service vendors. For a time, I constantly saw questions about proprietary review platforms. We would be asked about all of the applications we used to process, analyze and host ESI and then there was a bias that we also had to have developed our own software. It was interesting to me that service organizations, such as ours, spent an enormous amount of time vetting best-of-breed applications to handle client data and were also expected to develop, maintain, and often sell as a locally installable offering, our own platform. I understood that some prospective clients thought that we would have more control over our own application in order to customize and/or make fixes or that they believed that an integrated proprietary platform would be more efficient and cheaper. However, I felt that in some cases, there was a conflict between finding that best-of-breed and also selling a home grown alternative.
Interestingly, this aching need for a proprietary option, seemed to drop off the RFP radar when a new review platform became very popular and everyone wanted us to offer that. In the case of proprietary platforms, the trend seemed to be a fad.
Which brings me to the issue of ECA. As I mentioned, early case assessment was a very sexy topic before TAR pushed it off the top of the charts but I have noticed recently that the term ECA is being used by some in the industry as a synonym for preprocessing in order to cull data. While ECA tools or ECA features of eDiscovery platforms can be used to cull data, ECA should not be used synonymously with “preprocessing” either in RFPs or proposals.
As I have written in the past and observed many eDiscovery thought-leaders explain, ECA is a process. The goal of the ECA process is to understand a matter in its earliest stages in order to prepare for meet and confer and to make decisions such as whether or not to file as a Plaintiff, whether or not to settle, estimate how many custodians might be preserved, what kinds of data are at issue, approximate eDiscovery costs, as well as formulate an overall strategy.
I think that the confusion stems from the problem that, although ECA was seen as a trend, most potential users didn’t understand it. They thought it was some kind of magic wand they could wave over their entire litigation and mysteriously bring the hot/responsive documents out of hiding with little or no participation from the litigating attorneys.
Certainly, ECA can be achieved with the help of applications that offer analytics, sampling, data mapping, and culling tools, but, as I just said, it is not a completely automated process. An attorney with a deep understanding of the matter, must interact with the ECA application to get the right, targeted data into it, assist in managing any analytics and benefit from the information that comes out.
I believe that many attorneys, hoping that ECA would be the magic bullet, rushed to add the functionality to RFI/RFPs. In response, some software providers attempted to describe their tools as having ECA capabilities and some service providers managed to add some kind of ECA consulting or analytics to their work flows. However, too few clients were willing to truly participate in ECA so the tools and service offerings didn’t get enough of a workout. I believe the lack of true ECA experiences has lead to a kind of vestigial use of the term in place of the also used “pre-processing”.
Certainly, a pre-processing phase at a lower price-point than “processing for review”, that enables various forms of analytics, filtering, culling and searching is a great addition to an eDiscovery workflow, but please don’t call it “early case assessment”. And, when crafting an RFI/RFP, please ask for features or services that will be used by your organization and aren’t just an interesting, “luxury item”. The addition of non- essential items in an RFP can obscure the answers to more important questions.
I have included detailed best practices related to RFI/RFP creation in my eDJ Research Report: Ten Components Of An Effective Vendor Selection Process and I know there will be an interesting discussion of RFP drafting and grading at my eDJ Bootcamp: Selecting eDiscovery Technology and Service Solutions being held Thursday May 16th at the New York Hilton.
Babs Deacon can be reached at babs@eDJGroupInc.com for offline comments or questions. Her active research topics for 2013 will be solely focused on vendor selection.
Find Babs at the following events:
- eDJ Boot Camp New York: Selecting eDiscovery Technology & Service Solutions, May 16, 2013, New York, New York
- ILTA Conference, August 18-22, Las Vegas, NV
Connect with Babs: