Reality Check from Steve Lief, Esq.: Are You Using the 5 Day Rule & Complaining About eDiscovery?

10 Jul 2014 9:51 PM | Chere Estrin (Administrator)

Reality Check!!


I was at a meeting with a potential client recently, and was presented with a set of their predominant case-teams' dis-satisfactions with both their external and internal ediscovery - litigation support teams and providers.  One of their most prominent complaints was the time it took to load data received on any of their matters. 


They operated on a 5-day rule, that is to say 5 days following receipt of any data, it was supposed to be loaded ready for review. That sounded like a fairly generous time-frame to me, as I've rarely worked for patient litigation teams, and that sounded like a rather reasonable amount of time to load data into any database.


I've frequently been involved in situations where immediate attention to document loading was required, such as when, during a deposition, documents were produced and needed to be marked, numbered and loaded so they could be instantly used and recorded.  Quite different than any 5-day protocol. 


It might also take as much time to load a single document as 1,000 because the data load set-up time was more significant than the time it might take to load any reasonable bunch of documents.

So what was the problem?  Where was the reality check disconnect??

Turns out that documents could be received in any of their many - several offices.  The attorneys receiving them would need to cross-ship and deliver the pages to be scanned or discs to be loaded to the main support office for processing and ingestion.  That could easily take a day or two, and likewise, the attorney also might not get to this re-delivery task for a day or two. 


With a 5-day load standard, subtracting 2 or 4 days from the task made everything into a [un]fairly critical crisis situation! 


Simple remedy -

When analyzing the 5-day from receipt standard expectation, I pointed out that they need to start the clock to when the processing folks got the data in their own hands. 


If the case-team wanted their data loaded sooner, all they needed to do was turn around the data to the support folks sooner, whether by FTP or internal network upload, expedite the cross-shipping, or eliminate introducing any delays of their own doing.


Actually easy to fix once this was pointed out to them. It was unfortunately easier for them to assign blame than admit they were really part of the problem.  Upon review, however, while their standard protocol was arguably generous, their own behavior was not.  They had no one to blame but themselves for delay. 


Reality Check!!


Powered by Wild Apricot Membership Software