I agree with Larry. The notion of a standard for search acceptability is problematic in many ways. It's rather like defining a standard for how big a hole to dig. Is the hole big enough? Well, it depends -- on a lot of things. Not least of them are the areas Larry points out, such as widely differing topics areas that make a single standard in and of itself a can of worms (and of course, the most common problem -- what if the data's just in lousy shape?), but also many other things -- suppose such a search standard could be defined, but it was very expensive to implement -- how do you reconcile this with smaller cases, or with parties that don't have unlimited budgets, or with speedy trial rules or a hundred other things that make optimal practice impractical even when theoretically possible?
The other fundamental issue you'd run into is that judges always have discretion to make exceptions, and they need it, for all the reasons above and many others. And lawyers aren't in court to blandly acquiesce in letting the other side do whatever they think best. They're there to win for their clients. If it suits his/her client's case, any lawyer worth his/her salt will cheerfully stand there and argue that the standard: isn't applicable/isn't any good/is the wrong one/is outdated/is unrealistic/isn't stringent enough in this case/is too stringent in this case/etc., etc., etc. and they'll try to sell it to the judge to use that discretion to make some sort of exception, and just as sure as God made little green apples they'd show up with some experts who agreed with them. And many times, they'll succeed in getting the judge to do something. So then, after you've got a few of these cases on the books, the standard itself is subject to common law interpretation by resort to case law and the whole notion of a standard that doesn't need case decisions to construe and apply falls apart.
Best regards,
John
John Montaņa
Montaņa & Associates
29 Parsons Road
Landenberg Pennsylvania 19350
610-255-1588
484-653-8422 mobile
[log in to unmask]
www.montana-associates.com
twitter: @johncmontana
On Jun 30, 2011, at 10:53 AM, Larry Medina wrote:
> Sadly this is another case of people/organizations having an unclear
> understanding of what a "Standard" is.
>
> There is the potential to develop a set of guidelines or a recommended
> practice, but the possibility of a TRUE "Standard" in this area seems highly
> unlikely. there are severely different opinions on what each side
> expects/desires in an eDiscovery case.
>
> To develop a Standard, there are four cardinal principles that must be met
> by the body performing the work: Balance, Openness, Due Process and
> Consensus. It5 hard to believe that individuals could come together
> representing both sides of this issue along with parties from the Court to
> offer their objective opinion and reach consensus. Even groups such as
> Sedona would not qualify to meet the ANSI/ISO Requirements.
>
> At some point, "Guidelines" or "Recommended Practices" may be developed to
> state what minimums should be met by parties involved in eDiscovery to
> satisfy the needs of both parties involved and to ensure the Court doesn't
> have to repeatedly rule on what needs to be performed, but not a "Standard".
>
> Every case is different- some involve Intellectual Property, Confidential,
> Classified, Privacy, Medical, Financial Employment and other sensitive or
> business proprietary information and in these cases, exceptions are
> regularly granted to parties involved- how would any of these be addressed
> in a Standard?
>
> Larry
> [log in to unmask]
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
> mailto:[log in to unmask]
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
