How to pick eDiscovery Software
by Kiwi Camara
Concord DT (800) 246-7881
Here, from most important to least, are the factors you should consider in picking ediscovery software:
Speed
The most important feature of ediscovery software is speed. Search, rendering documents, and navigating through results and documents should all be as fast as possible. In Disco, for example, searches take about 1/3
of a second and rendering and navigating take about 1/10 of a second. Speed is enough to seriously reduce the landscape of software options.
Why is speed so important? The single biggest frustration you will experience is slowness. It makes the software a pain to use and the review intolerable. Some people try to quantify the cost of slowness in the lawyer time that is wasted waiting for searches to run or documents to load. The real harm is more insidious: because slowness makes the user experience awful, lawyers stop doing document review, or even searching for critical documents in the database, as soon as they are senior enough to assign these tasks to someone else. Fast software means better lawyers will get their hands dirty in the evidence.
How do you test speed? This is actually harder than it sounds. Most vendors do not have an online demo. When they do a demo for you, most vendors do it on a limited subset of the Enron database — sometimes as small as 50 documents, or 500. The speed you see on a miniature database is nothing like the speed you will see on 500,000 documents (thefull Enron database) or 5,000,000 documents (a typical commercial case). Also, most vendors will show you a demo running locally on their machine; this may be nothing like the speeds you get on actual databases running remotely on the vendor’s servers.
Always ask to test software on the full Enron database on the servers you would have access to as a customer. If a vendor won’t do this, run away. I cannot emphasize enough how important speed is: if software fails the speed test, it doesn’t matter what other features it has or lacks; no one will get that far before coming to hate using it. You would not do badly if (among the leading products) you selected solely based on speed.
“The single biggest frustration you will experience is slowness”
Cost
Cost has two components: predictability and the total amount. On predictability, you should demand a cost structure that lets you know, at the outset, or at least as soon as you know how much data is involved, how much your ediscovery software bill will be. Flat, all-inclusive per-gigabyte pricing is an example of the kind of pricing you want.
What do you often see instead? It is not unusual to see multipage price sheets with separate prices for each processing option, separate prices for different kinds of hosting, and separate prices for various stamping and production options. Pricing like this means you have no real idea what you will wind up paying — and means that in-house counsel at the client cannot budget accurately. Many separate pricing line items often means that the vendor (or the underlying technology company, if your vendor is a channel partner) doesn’t actually own the technology at issue. For example, many people license their document viewer from Oracle or their near-duplicate technology from Equivio, and have to pay license fees each time they use this licensed software. The line item is how they cover these costs. An ediscovery product that is really just a bunch of licensed software glued together will never work as smoothly as an integrated solution built from the ground up.
On the total amount, avoid being gouged. As a general baseline, you should try to never pay more than $250 / GB for processing, $25 / GB /month for hosting, and $100 / GB for production. Even these prices can often be beat, for example by almost all Disco’s channel partners. If you are paying north of these amounts, or if the prices you pay aren’t all inclusive, you really need to shop. One way to think about prices is to consider a vendor’s costs. Anything that a machine does should be close to free. While the software that un packs container files like PSTs, assembles emails and attachments into families, assembles email families into conversations, does OCR, detects duplicates and related documents, images and endorses documents, and the like is not trivial to develop, once it is developed it costs essentially nothing to run. By contrast, when you store more data, the vendor’s costs do increase, because the vendor has to pay for more storage space. If you
see yourself paying a premium for things that you know software is doing automatically, you should be skeptical: either it isn’t automatic, and the “A flat, all-inclusive per-gigabyte pricing is an example of the kind of pricing you want” vendor’s technology isn’t up to snuff; or the vendor is trying to rip you off.
Features
Features are where many people get into trouble. Think to yourself about what features you really use in a review and make sure that those features are implemented as elegantly as possible.
What are those features? For 90% of cases, what you want to focus on is processing, search, sort, review, tagging, mass tagging, privilege log, stamping, and production. If you have these features, you have everything you need — and everything you will actually use. Other features are clutter. (Trust me, you will never use the web of email.)
What does it mean for those features to be implemented elegantly? Processing should just work and should be automatic; when files can’t be processed (for example, because passwords haven’t been provided), you should get a simple report identifying the files that need further action. All search options should be readily available on a single screen (Disco uses a single, simple search box) in a way users understand without training (Disco uses Westlaw- and Lexis-style search syntax that all lawyers already know). Reviewing and tagging should be powered by keyboard shortcuts that let reviewers move through documents as quickly as possible. Stamping and production should be run by the user through an interface that provides sensible defaults (e.g., about output formats), described in plain English. And, above all, this must all be fast.
Make sure that your product satisfies these first two requirements before going on to consider additional features. When you do look at other features, think carefully about whether you will really use them, or whether they just make the product harder to use. Detailed user analytics are a good example of an add-on feature that may be useful in particular cases: if you have a large number of reviewers you don’t know well contract attorneys), you may benefit from software that tells you exactly what theytagged each hour or each day, how often their tags were overturned by more senior reviewers, how long they spent in the system, and the like. In general, though, quality over quantity should be your motto when it comes to features. “Quality over quantity should be your motto”
Support
The less you need it, the better. (Support is different from training; training should be readily available and done at the vendor’s cost.) What you want to hear from your vendor is not that there is a large support team available to field calls 24/7, it’s that customers never seem to need that kind of support. Put another way, the best kind of support is a product that just works, and that lets you do everything you need to do (including, for example, production) on your own.
If you are dealing with a good product and you nonetheless have a realproblem, the most important thing is not how quickly you can get to a line support person — it is how quickly you can get the real problem fixed.
This means you want support people who can escalate issues to engineering and an engineering team that can and will make software changes to address your problem. To get this, you need to deal with a genuine technology company (no one can fix bugs in a viewer licensed from Oracle) building on a platform that allows for rapid updates (web-based technology where the server code can be updated without you having to do anything). Ask for stories about how your candidate vendors have fixed code problems for other users in the past.
Finally, you want to make sure that line support (“how do I run this kind of search?”) is easy to get when users do need it. Ideally, it should be available through a chat box in the software so that the user doesn’t have to find a phone number or interrupt her work flow in order to ask a question. If you know that your users are support heavy, you should also consider buying through a channel partner who specializes in providing a robust support organization; this can be an important area in which channel partners add value.
Maturity
Litigation exposes bugs and design flaws. There is no substitute for using software that has been battle tested, preferably by others, and that is in active development in response to feedback from the battlefield. Of course, the more established the company you deal with, the harder it will be to get changes or customizations done for your particular project; old software ossifies. You want a product that is modern and changing, “End-to-end managed services solution” but that is in wide enough use to give you confidence that others have encountered and resolved any big problems already.
Ecosystem
You will be doing more than just processing, review, and production; you may well need help with collection and forensics, paper production, and trial graphics, for example, or you may need project managers or actual
reviewers to assist in the actual document review. This is where a technology company’s channel partners really shine: a great channel partner makes money not just by marking up software (adding value purely through sales), but by bundling that software with the other products and services that you as a litigator need and by putting its name and credibility behind the bundle as a whole. A healthy ecosystem of resellers and compatible complementary products is a good sign.
Defensibility
Can your vendor explain how its technology works? Does the software log the decisions that you and your team make in the course of the document review? The answers to these questions have to be “yes” before you are in a position to defend the results of a review to a skeptical opposing party or to the Court. (I include this item because it is important; I rank it lowbecause it is actually much less important than it is often made out to be. Discovery battles over technology are the exception, not the rule.) Interoperability . You should never use software with proprietary formats. You should always be able to get data into the software that comes in industry-standard formats (EDRM or OPT load files, for example), and you should always be able to get your data out whenever you want to and in a format that other software (your own, or the software of parties to whom you are producing documents) can operate on. “A healthy ecosystem is a good sign”
We believe Disco scores well on each of these eight factors; they are what guided Disco’s design. Together they paint a picture of ideal discovery software that lets lawyers get their work done quickly, that anticipates what they want and gives them what they need as simply and as elegantly as possible; software that helps lawyers find evidence faster.
