Litigation Support Technical Standards
by Mark Lieb



Sample Content
  • Table of Contents
  • Introduction
  • For Vendors
  • For Firms


  • Business Standards
  • Cost Codes
  • Outgoing Media Kit
  • RFQs
  • Quotes


  • Technical Standards
  • Media Labels
  • Bates Schemes
  • Native Files
  • File-Folder Names


  • Downloads
  • The Standard
  • The Book


  • Software Load Files
  • CaseSoft
  • IPRO
  • To Be Added


  • What Not To Do
  • Media Labels
  • Load Files
  • Transcripts
  • General Errors


  • More Resources
  • LSVA
  • Litigation Support
  • Ad Litem Consulting


  • Mark Lieb
    Ad Litem Consulting



    litgation





    Home | TOC | Previous | Next | Download


    5.11 Real Experiences

     

    All of the examples in the "things not to do" section are, unfortunately, real. These types of problems eat up a lot of billable time. As the document matures, the list will probably get longer. There are a lot of creative people out there working the controls. What they create is what your firm will use for review, productions and exhibits.

     

    People are welcome to submit their experiences at http://www.eDiscovery.org.

     

    These examples are not meant to criticize any product or person. These examples explain the types of problems one may encounter, by product, regardless of product, firm, vendor or persons involved. One goal of this document is to give both good and bad examples that anyone technical person can use to improve their products.

     

    If you use this document, please let me know.

     

     


    Home | TOC | Previous | Next | Download


    Contact Ad Litem

    (C)2005 Ad Litem Consulting, Inc.









    About Litigation Support Technical Standards

    This document was initially designed to eliminate any discrepancy between firm technical needs and how the vendor created the technical aspect of their products. Litigation Support spends needless hours changing the vendor delivery. The firm pays for product that litigation support will have to modify. Today, the document covers as many technical requirements as possible for as many types of discovery and software as possible.

    To get a good idea of the reason for these explicit directions, please visit the final section of this document entitled, “Things not to do”. All of these examples are from real life. All of these examples caused headaches, delaying reviews, productions and more.

    I hope that this document is helpful to you.

























    Template by Steves Templates