The document provides tips for successfully evaluating eDiscovery software demos. It recommends knowing your goals for the software, which team members will use it, any security boundaries, researching potential partners, preparing for demos, and conducting a proof of concept test. The key steps are to define the problems you hope to solve, understand your team's needs, set expectations for demos based on your requirements, bring the right stakeholders to demos, and thoroughly test the top solution.

1. - A PUBLICATION OF iCONTROL ESI -
Top Tips to a
Successful
eDiscovery Software
Demo

2. TABLE OF CONTENTS
Intro
Know Your Goals
Know Your Players
Know Your Boundaries
Research Your Potential
Partners
Prepare for Your Demos
Don’t Forget the Proof of
Concept
1
2
3
4
5
6

3. Introduction.
Because the use of technology to manage discovery has become so
widespread, we take for granted that those seeking software solutions
to discovery needs have a good understanding of a sound software
evaluation process. Over the last few months, however, folks attending
our software solution demos have admitted they don’t know how to
make the most of an evaluation, or what to ask a company when
evaluating software, and there’s no published guide to how to
evaluate. It seems appropriate to share some of our basic advice for
software demos. These guidelines will help you make the most of your
time in reviewing software solutions.
They cover:
Know Your Goals
Know Your Players
Know Your Boundaries
Research Your Potential Partners
Prepare for Your Demos
Don’t Forget the Proof of Concept

4. Know Your Goals
CHAPTER ONE
1

5. Know Your Goals.
Prepare a list of the business problems you are trying to solve with
technology. Generally, we need solutions that get us to the most
important and relevant documents as quickly and efficiently as
possible. Tools contributing to that begin at retention and
preservation, and end at review and production. First, decide where in
that spectrum you are shopping. You may be looking for an “end-to-
end” solution or a new answer to just part of the process.
With that scope set, you are ready to think about the specifics you
would like to see in a potential new solution. It can be useful to ask
questions like… What does my current solution do well? What would I
like it to do better or more effectively? What potentially valuable
features are simply missing from my current process?

6. Prepare a list of the business
problems you are trying to solve
with technology.“

7. Know Your Players
CHAPTER TWO
2

8. Know Your Players.
Think through your organization and which of your team will
most likely play roles in use and support. How will you use the
software? Who else will use the software, and are their needs
any different than your own? What training will you, and your
team require? Who will support and administer your use of the
software? Knowing (or at least having some idea) the answers
to these questions helps you identify the players that you may
want to involve in the remainder of the process, giving your
selection a better chance of acceptance and successful
deployment.

9. Think through your organization
and which of your team will most
likely play roles in use and support.“

10. Know Your Boundaries
CHAPTER THREE
3

11. Know Your Boundaries.
Do you need all software installs and data to remain behind your
corporate firewall? Is Software or Infrastructure as a service ok?
Fully cloud-based solutions? For each one of those possible
deployment methods, do you have specific security or system
administration requirements that your selected solution must
adhere too. These, are but a few examples of the many
questions you should ask. Your potential partners will
undoubtedly be willing and able to help you track down the
answers to these questions. That said, to the extent you can
track down the answers, you can use that information to provide
better focus for your search, and save time you might otherwise
use in evaluating solutions that aren’t a good fit for your
organization.

12. Do you need all software installs
and data to remain behind your
corporate firewall?
“

13. Research Your Potential
Partners
CHAPTER FOUR
4

14. Research Your Potential
Partners.
As with previous guidelines, your goal here is to focus your search.
You don’t likely have time to look at solutions from a large list of
partners. You want to establish criteria that ensure the few
solutions you spend significant time evaluating are from partners
that meet or exceed the thresholds you establish here.
eDiscovery is highly specialized and expanding in skillsets required
from IT to legal to Privacy and Security. Look for vendors who
understand the document types being produced so they
understand developing software to manage them. Make sure that
they understand the privacy and security issues associated with
litigation.
Learn about their reputation and time in the industry, and the
availability of support staff in the event of issues with the software.

15. Research Your Potential
Partners.
Examples of Questions to Ask
• How long has the company been providing eDiscovery
software?
• What is the company’s history in eDiscovery?
• What is their general reputation in the industry?
• Does the company have a list of current and past clients to
serve as references?
• What types of projects has the company worked on in the
past?
• What is the most complex matter they have handled?
• Do they have a variety of experts in legal, technical, privacy,
ESI management?
• Is this a company with a stable history indicating that they are
here for the long run to support their product?
• Are they easy to work with?
• Do they offer training?
• What is the software update cycle and how are updates to
software applied?

16. Prepare for Your Demos
CHAPTER FIVE
5

17. Prepare for Your Demos.
Set expectations. Provide your potential partners with (at least in
summary) the Goals, Players, and boundaries that you identify. Set
the expectation that you want to see a demo focused on those
requirements specific to your organization. If creating a demo that
addresses your specific requirements is a challenge for any
potential partner, that’s probably a good sign that their solution
isn’t right for you.
Bring the right team with you so you can get as many of your
questions answered at the demo as possible. Consider your
Players, and think about inviting some or all of them to attend your
demos. Let each potential attendee know why you believe there
attendance to be important, and what you are relying on them to
listen for. Ask each to come prepared with questions focused in
their area of expertise. For example, you may want to include
someone from both IT and legal so that you can ensure the
software deployment fits within your organization’s security
guidelines and provides for a defensible result.

18. Prepare for Your Demos.
This list of example questions likely highlights the need to involve
multiple areas of expertise. These are the types of questions you
should ask/consider in every software demo (it is helpful to provide
these questions to the potential partner ahead of time):
• Is the UI pleasing?
• Is the software easy to use?
• How are your features different from others who offer this
technology?
• What about security and privacy? Are there any risks associated
with using your technology?
• Is the software cloud-based (SaaS) or is it a behind-the-firewall
installation?
• Do you have infrastructure as a service models (IaaS)

19. Develop a sheet with
Criteria …“
Finally, develop a sheet with criteria and grade each vendor on the same
criteria. Virtually all applications you evaluate will have different feature
sets. A feature that is present in one application may not be present in
another. Identify those features that are important to you and indicate
the critically of those that are MUST HAVE vs something less important, or
optional. The above table is an example of some.

20. Don’t Forget the Proof
of Concept
CHAPTER SIX
6

21. Don’t Forget the Proof of
Concept (POC).
Before you make your final decision, conduct a POC. Someone
once said that the “proof of the pudding is in the eating,” and
that’s true here as well. The only true way to know whether
you’ve made the right choice is to test drive the software before
you make a commitment. While the best possible POC is a real
project that will get everyone undivided attention, a successful
POC can also be conducted on “test data.” As you go through
your POC, make a list of the steps that will follow the POC. This
is especially important if you are conducting a POC of multiple
software applications. Be sure that you know, at a minimum, the
“success factors” that will be used to judge the whether the POC
is successful. The criteria sheet you use for grading the vendor
demos, should serve as a starting point for grading the success of
each POC. As the POC progresses, you should share your results,
against the selected criteria with the software company, so that
you can discuss and then assign each criterion a PASS or FAIL
result.

22. The proof of the pudding is in
the eating …“
At the end of the POC, your review of the PASS or
FAIL results for the packages you reviewed will,
more often than not, give you the clear winner.

23. Questions?
We’re here to answer your questions and to help.
Check out our other resources at
www.icontrolesi.com
While there, take a tour of
Recenseo and Envize