Migrated from eDJGroupInc.com. Author: Greg Buckles. Published: 2010-01-26 17:26:52 The eDiscovery buzz word these days is ‘ECA’ or Early Case Assessment. But what does that really mean and what software functionality really comprises an ‘ECA solution’? The current Wikipedia definition of ECA appears to focus purely on scanning and generating reports on sources of unstructured ESI to derive an estimate of the potential cost of discovery. This definition covers part of what I call the Tactical Scope Assessment, but completely misses the initial Strategic Assessment that defines the fact pattern and potential key evidence that counsel needs to make a liability judgment. Senior management usually wants to know what we think really happened and what proof there is before they start spending money on software or services to scope the potential discovery costs.So what if any are the differences between a traditional processing platform and an ‘ECA solution’? Both enable the user to index, search and preview items, the minimum required to make strategic decisions early in the case lifecycle. Most full processing platforms such as LAW or Discover-e process and explode a collection copy rather than the source ESI directly from the custodian’s location. This also requires a reasonably robust system, a technical user and can eat up a lot of storage overhead for the exploded (unpacking zips and email attachments) data and index. Up until recently, all of these systems had a volume (per GB) pricing model. This meant that a company had to spend time and money to collect ESI and have it rendered into a searchable form. All of this before management even had a good idea of the potential exposure. Now you can see why corporate legal departments have not really embraced a full ECA process up to this point.So what makes an ‘ECA solution’ different? Customers expect the software to enable them to search and profile data either in place or at least without any additional expense or pre-processing. This shifts the user from a dedicated Litsupport Tech to an associate or paralegal. The expectation is that the software can be pointed at a data source and be searched, profiled or explored without undue cost or effort. So the real differences are not in actual functionality, but in the GUI and workflow.So with this foundation assumption, we can take a look at what functionality is really needed for ECA activities. I do not consider any application to provide a ‘solution’, but we can at least get a better idea of what can support your process.Strategic Assessment Functions: Goal- Support fact finding investigation and liability assessments.
- Index and Boolean Search – in place or at least without full explosion
- Preview or Review of Native ESI – ability to view items and select or mark key items
- Inventory or Catalog Reports – scan and report on potential network shares, desktops or collections so that investigators can focus on relevant areas
- Custodian or User Reports – extraction of user names, email addresses, etc. to support investigation interviews and searches
There are many more features, especially analytics, that add value during this phase, but these seem to be the minimum required to support the goal. Tactical Assessment Functions:Goal – To define and quantify the scope and characteristics of potential discovery to support budget decisions, Rule 26(f) scope negotiations and other decisions in the Identification phase.
- Summary and detail reports on potential ESI sources. See earlyCASE for a good list of assessment reports
- Extraction of domain, custodian, source and chronology characteristics to enable user to define and document relevant potential scope
- Search term and criteria break down analysis, including term frequency, term clusters, directionality (inbound vs outbound) and other search relevance criteria for negotiation support. Term or hit frequency is critical to support arguments about overly broad criteria
- Sampling searches to document exclusion of non-relevant sources
- Cost projection tools that enable user to use known or estimated cost factors to calculate projected cost of potential collection criteria through discovery lifecycle
The bottom line with applications or appliances intended to support your initial strategic and tactical decisions is that they have to be baked into your overall event response process. They have to be accessible and usable by the first responders without requiring specific budget approval or network space allocation. This is where the traditional processing tools have fallen short, even when they are installed behind the corporate firewall. Enterprise search systems such as Autonomy IDOL, StoredIQ, Recommind and others promise live search of the content in place, but you need to look at how they will support your decisions and workflow. Enterprise archives like Symantec’s Enterprise Vault, EMC’s SourceOne and all the others enable search and some level of reporting on archived content, but unless you have an integrated data lifecycle management system, you may still have to look at live sources.If you clearly define your goals and the functionality that supports them, you can figure out one or more products to get you there. You may only need a desktop search engine like dtSearch, ISYS, Windows Desktop or even Google Desktop, but be careful when you move to the actual negotiated searches or filters. The processing platforms explode and track items for a reason and under an entirely different level of quality control requirements. Acquiring and implementing good tools into your event response process has one of the fastest Return on Investment (ROI) rates, but only if you use them consistently and document the impact of early case decisions.