 |
|
|
Access-Cadabra! Is Microsoft Access the Magic Database Answer for Your Complex Litigation?
by Rachel Levine
INTRODUCTION
Litigation is an organizational nightmare. Facts and
figures, depositions and dockets can get lost in mountains
of paper -- or jumbled in an attorney's memory. The advent
of litigation management software promised to ease the
crunch. Litigation support providers assured law firms that
their systems would allow attorneys and their staff to throw
the information into a computer, wave a magic wand, and have
it answer their questions.
These systems, essentially large databases -- do deliver.
Minus the magic wand, they offer a quick way to search and
retrieve information in a complex -- or not-so-complex case.
While many software companies dedicate themselves solely to
developing litigation- and case-management tools, firms
cling to the systems they already have in place. Or, in
others, firm managers and information technology
professionals adapt an existing database to the firm's
litigation management needs. Because Microsoft Office has
saturated the office environment, many law firms have
embraced Microsoft Access simply because it's there.
As a database developer with fifteen years' experience, I've lived through several firms' attempts to tame complex litigation. In the old days, mere mortals didn't dream of designing their own databases. The white magic called "programming" was reserved for a select few. With Access, Microsoft is trying to make this "magic" accessible to the masses. And for small, simple projects the masses can probably handle it. To use Access for complex litigation however, you are going to need real expertise and resources.
If you are thinking of using Access for litigation
management, check with your information technology (IT)
department. You'll need their resources and expertise. If
you don't have an IT department -- or it doesn't have time
to help -- you and your staff can go it alone.
Essentially, you will be setting up a mini IT department.
This article will help you decide if doing so makes sense
for you.
WHY USE A DATABASE AT ALL?
Firms use databases to manage litigation because they want
quick and easy reports and information about a case. Take,
for example, a product liability case against a large
pharmaceuticals company. (Your client, Acme Drug Co., is
named in hundreds of cases and each case can have dozens of
plaintiffs.) The firm needs to capture a lot of
information:
1. Who took which drugs for how long?
2. Who is claiming what?
3. Who saw which doctors?
4. Who was deposed, when and where, in reference to which
case(s)?
5. Which exhibits were used in which depositions?
6. Which complaints were not served properly?
7. Who represents whom?
This list represents only a handful of the kinds of queries
you can "ask" of a database. These bits of information --
and thousands of other facts -- are keys to success. Your
attorneys just need to find the right piece.
WHAT ACCESS IS AND ISN'T
Microsoft Access is a database that can be used for
litigation management -- although litigation management was
not a goal of its programmers. There are different kinds of
databases. Access is called a "Relational Database
Management System." (RDBMS) Simply put: it stores data in
"tables" that the user designs and creates. The process of
figuring out which tables are needed and how they relate to
each other is where the "white magic" comes in. There are
rules about this, and the application of these rules is part
science and part art. (The creator of this theory of
relational tables was a man named E.J. Codd who worked for
IBM in the 1970s. His books on the subject are almost
impenetrable, but the basic concepts are not that difficult
to understand.)
All database programmers -- whether working with big
companies like Sybase or Oracle, or out of their own offices
-- spend a good deal of time designing these tables at the
beginning of a project so they don't violate the important
rules of relational design. If the rules are violated,
users will uncover redundant information that is impossible
to find and change when needed. And, users' queries may
never return all the information they should -- and users
won't know the difference.
The proper database design will enable you to get data out
of your system any way you need to, regardless of when or
how you entered the data. To put it another way: you don't
have to know at the beginning of the project exactly which
reports you will want down the road. Once the system has
been programmed and the data has been entered, users decide
how they want it served up.
Microsoft Access is not simply "Excel on steroids."
A
spreadsheet is a good tool for accounting purposes, or for
listing any information in simple row-and-column format. It
gets tricky (or downright impossible) to use this kind of
program when you need to relate the information in one cell
or row or column to other information on the sheet. The spreadsheet approach is called a 'flat file' and The Relational Model was developed to solve the
problems created by flat files, but many law firms use
Access as if it were a flat file program. Of course, you
can create flat files in Access. But to get the most out of
the program, Access requires you to use the Relational
Model. When you give Access what it wants, it will reward
you by making many things easier. If you don't, it won't
squawk, but it will make your life pretty miserable later on
when things become more complicated.
Flat files appeal to users because everything they need is
in ONE BIG FILE that's easy to create and easy to use.
Learning and using the Relational Model is not quite as
easy.
Access is not a "document handling system"
like Summation, Concordance, or Doculex.
Most of these
products allow you to set up fields and index them for
future retrieval. The problem is they are document-centric,
not case-centric. In other words, they manage documents,
not cases. Many of these products will allow you to link
Access to a document so that you can view the imaged
document. Together, Access and a document handling system
are very powerful, but they do very different things and
shouldn't be mistaken for the other.
WHY USE ACCESS AND NOT SOME OTHER DATABASE SOFTWARE?
Firm managers have much to consider before they commit to
database program: the size and scope of the project, the
software cost, and maintenance all play a role.
The big names in the database industry are Oracle, Sybase
and Microsoft SQL Server. These products are the ones
designed for "the enterprise" -- your entire firm. These
products can run your time and billing program, your client
accounting system, and practically everything else you do or
store electronically. But they're expensive to purchase,
and they require real expertise to set up and maintain.
(You might have heard the term "DBA-DataBase Administrator."
These folks are the "high priests" of enterprise databases,
and they usually command high salaries as well.) These
programs can handle hundreds of simultaneous users and
millions of records. Access cannot.
If you're in the market for a smaller, cheaper, easier to
maintain database that is also relational (not a flat file),
you have a few choices. You may remember products called
dBASE, Foxpro, and Paradox. They are in the same category
as Access: "relational desktop databases." These products
still exist but the problem is that they have lost market
share to Access. As a result, many firms are wary of
getting involved with them for fear they will one day cease
to exist at all and because it is becoming increasingly
difficult to find qualified people to work with them. Lotus
Approach is also a relational desktop product that gets good
reviews from users and, is said to work seamlessly with
Lotus Notes. So, if you are using Notes, you may want to
consider Approach for your database.
IS ACCESS RIGHT FOR YOU?
Firm managers need to assess up front which database they
plan to use -- and if they have the people who can use it.
Firms that wait until they are well into the case can still
automate, but they rush the process and may never benefit
from all the advantages of the software.
Richard Davis, Assistant Manager of Technical Litigation
Support Services for Cravath, Swaine & Moore, advises, "If
you don't have the people you need, acquire them early in
the process."
Sharri Wilner, a case manager at Simpson, Thacher, Bartlett
offers, "It's vital to understand everything this powerful
tool can do before you decide whether or not to use it."
If you don't know whether this kind of software is right for
your firm, keep these thoughts in mind:
1. The "right" technology may be people and paper, or it
might be computers and data. Being "high-tech" for its own
sake doesn't make much sense. How has the firm managed
large litigations in the past? If you, your attorneys and
clients are happy with the old-fashioned system, then stick
with it. However, if you've had problems quickly getting
your hands on information, mistakenly used unreliable
information, or thought you could have done a better job for
your client had you been able to compile statistics more
quickly and efficiently, then consider automation.
2. Do you have an Access programmer on staff or can you hire
a consultant if you need one? It's crucial that you have an
experienced database programmer on the team. If you can't
get such a person, don't attempt the project. As Wilner
points out, "A complex litigation is not the right project
for beginners to be introduced to Access."
3. Do you have someone who can be the project manager/point
person? Whether this person is an attorney or the lead
paralegal, he or she should not have many other
responsibilities in the early stages of the project. This
person must be computer literate, open to learning new
things, and squarely behind the automation project.
4. Are your paralegals computer literate and open to
learning new things? If they aren't, you will either have
to abandon the project entirely or bring in new paralegals
for this case. Don't bother trying to force staff to "learn
computers" right now. That's a long-term, strategic goal
for the firm as a whole. Richard Davis finds that "The
biggest stumbling block I have seen in the litigation
automation process is the human skill and attitude
component. It is critical to assess the computer literacy
of the team members and stack computer related tasks,
objectives and functions on those who have the right skills
and attitude."
5. Are your attorneys behind the idea of automating this
case? Most of them won't be investing much time in the
development process, but some will be called on to
contribute ideas and answer questions. Their input will be
crucial to the success of the project so be sure the
attorneys who matter are behind the automation idea.
MOVING FORWARD WITH ACCESS
You've met with your firm's attorneys and paralegals.
They're ready to automate their litigation pipeline (or hone
their automation to better serve clients). What can you do
to ensure continued success? Keep these suggestions in
mind:
1. Be sure you have (or can hire) a "database programmer."
"Developer" and "programmer" used to be synonymous. The
problem these days is that people call themselves all kinds
of things and not always with intent to deceive. I've met
"programmers" who never used anything but Access. Using the
wizards and macros, they created some very nice projects and
thought that constituted programming. They called
themselves "programmers" even though they couldn't write any
code and were not very well versed with setting up tables
properly. In short, they didn't even know what they didn't
know. On the other hand, there are veteran programmers who
still call themselves "developers." So, ignore the
descriptions and focus on the skill set.
A database programmer understands the relational model and
will set up your tables correctly, in addition to knowing
the ins and outs of Access. (Complex litigation usually
requires at least thirty tables, often more.) If you are
not sure how to tell who knows what, ask someone in the
computer department who is a database programmer (not
necessarily with Access) to help with the interviewing. Or,
you might hire an Access consultant who isn't available for
the entire project but can help you hire the right person.
If you have a PC User Group in your town or city, that's a
good place to begin. There are also associations of
computer consultants all over the country.
For a complex litigation, here's the skill set your Access
programmer/developer needs:
-- Thorough knowledge of the Relational Model of Table
Design.
-- Good working knowledge of Access itself including the
programming language: "VBA," and some knowledge of SQL
("Structured Query Language").
-- Good interpersonal skills (necessary for eliciting
information and training).
-- The ability to dedicate all their time to the project for
the first six months, on-premises for much of that time, and
a commitment to be available as needed after the first six
months for debugging, enhancements, and training.
-- Some experience with litigation, if possible.
2. Get together with as many team members as possible to
flesh out what you want the system to do before you bring in
the programmer.
Getting everyone involved from the beginning will prevent
anyone from developing an "I was never consulted and
therefore won't cooperate" attitude. Richard Davis advises,
"Market your plan and get buy-in from the beginning." Get
everyone to discuss what they want/need the system to do.
The more you get on paper at the very beginning, the faster
the development will be and the better the result. Keep in
mind that there will be many more meetings of various team
members as the automation develops.
3. Assign one person as the programmer's point person.
The programmer will want detailed specifications from you.
Your point person will provide these specs, answer questions
and set priorities. Essentially, this person is a
go-between representing the team's needs to the programmer,
and the programmer's questions/needs to the team. If there
is a case manager, this is often the best person for this
position because their broad understanding of the case is
invaluable to the programmer and, since they will need to
know the database very well anyway, they may as well be in
on it during its development.
4. Keep the programmer "in the loop." The more knowledge
programmers have about the particular case, the better their
results will be. Working on my first fraud case, I was
unable to learn much about it. I had signed a
confidentially agreement of course, but information was
still not forthcoming. As I imported data and designed
tables, I figured out that it might be useful to know if one
person was on the board of directors for more than one
company and/or also owned a stake in another company, and
the like. When I asked if queries like these might be
helpful I was told "Not just helpful but essential!" This
is precisely the kind of thing they should have told me.
You can't assume your programmer knows anything about the
law or what it takes to build a good case. Ascertain how
much they know early on and then educate them as you go.
5. Expect the point person and key paralegals to get less
work done during database development.
A good programmer will hurl questions at you all the time.
Finding the answers can take real time. Often the
programmer will need to watch the paralegals do their work
to automate the work. And, the system will need to be
tested as it goes. The paralegals who will eventually do
the data entry should be in on the testing. If all this
time is not taken into account, the attrition rate will be
very high. I have seen burn out time and again (of case
managers, department managers, and paralegals) when the
database is being developed because no one anticipated how
much time and brain power would be needed. As a result, the
staff was expected to continue with their daily workload and
also to work with the programmer. This arrangement
handicaps the programmer and has a negative effect on team
morale.
6. Designate someone to keep a "Decision Log."
A decisions log tracks choices made about the database and
its use. For example: I ask the team, "When should a case
be entered into the system?" Someone responds, "As soon as
we are named." Someone else says "No, we will only enter
the case when we are served." A third person suggests, "We
enter the case only when we are served correctly." A
lively discussion follows with all parties making an awful
lot of sense. At the end of this discussion, a decision is
reached.
That decision was the result of a thought process that we
don't want to forget. Six months later, when someone asks
why a case is "missing" from the system, someone needs to
remember that only served cases are entered and the case in
question wasn't served yet. Of course, the next question is
always "Why are we doing it that way?" Without that log you
will be saying, "I can't recall but I know we discussed it
at length and this was the final decision." An answer like
that won't satisfy anyone and usually leads to even more
meetings where the same issues is discussed again.
Don't ask the programmer to be in charge of this log. The
programmer should be keeping their own notes, logs, etc.
The firm needs to own this information, written in clear
layman's terms so that anyone who joins the project at any
time can easily understand its history.
7. Decide early on who will be doing the data entry, or,
hire someone(s) specifically for this task.
Though a good programmer will design an interface (screens)
that won't allow bad or incorrect information into your
system, the data-entry people have to learn how to use the
system correctly. In complex litigations, one case can have
dozens of plaintiffs, and dozens of complaints can arrive
daily. Maintaining the data can be a full-time job (for any
number of people). If this work is simply added to the
current responsibilities of your staff, you risk it not
getting done well if at all.
8. Set up "data proofing" protocols as soon as the first
batch of data is entered into the system.
How can you be sure that the data being entered has been
entered correctly? Regardless of how well-intentioned and
careful data-entry people are, mistakes happen. Without a
way of proofing the data routinely, you may never know that
it is incorrect. For example, you may run a query that asks
for all the cases in California in which Company X is the
defendant and get back a number that looks correct.
Unfortunately, someone entered "Pennsylvania" accidentally
for a case that should have been California.
You will need tools to do this job. Ask your programmer to
set up a report that prints out everything in the system for
each case. This will be the tool you use to compare what is
in the system to the hard copy (pieces of paper) you were
working from. Sitting with the complaints, someone will
compare them to the printed report to ascertain if the
information on the complaint was entered into the system
correctly and note where mistakes were made.
It's not wise to have the same person who did the data-entry
do the proofing. I've seen this step bypassed often because
it is time consuming and tedious, but without it, even the
best system is pretty much worthless because no one can
count on the data being accurate.
9. Expect the development phase to take six months ... or
more.
This may seem excessive, but it's a brutally honest estimate
based on years of experience. Many factors influence the
speed of development, such as the programmer's other time
commitments, the programmer's experience levels (both with
Access and litigation), staff availability to work with the
programmer, staff cooperation, misunderstandings and/or
miscommunication, new ideas/decisions, and staff turnover.
10. Have one person designated as the "beta tester."
Not only Microsoft needs beta testers. Any system designed
by any programmer needs people to put it through its paces
and find the bugs. Once the beta tester gives the approval,
the system (or a new feature) can be released to the team.
11. Keep the old system in place until everyone involved
(attorneys, paralegals, programmer) all agree the new system
works properly and does everything it needs to do.
This is also called "running in parallel." You are keeping
up two systems, which means keeping track of the information
in more than one place. Sometimes the "old" system is an
old computer system you have to keep up, sometimes it's all
being done on paper. Either way, the old system must be
kept up to date for quite awhile and this is very
time-consuming ... so plan for it.
12. Understand that people's roles, workloads, and attitudes
will change as a result of automating many of the processes.
Some team members may feel "disempowered" by the system.
Others will rely heavily upon it and constantly find new
features they would like. Paralegal workloads will change
drastically once the system is in place. Some will have
much less work to do and you may find yourself needing fewer
of them. Those team members who are enthusiastic about
computers sometimes get sidetracked from their work by the
computer, and those who dislike the computer-related work
may feel threatened by it. The bottom line is that you will
need to keep an eye on the morale of the team (especially if
they have never worked on a litigation that was managed in
this way before).
After all this, you may be wondering if it's really worth it
to automate at all. Richard Davis makes the point that "the
long term benefit of using Access for a litigation is that
much of the time, effort and dollars spent acquiring the
skills, hardware and software for a particular project
become institutional in nature and will facilitate future
projects." In other words, everything learned by everyone
will surely be put to use again and again in future cases.
In fact, the database itself can be customized and reused
for other litigations.
CONCLUSION
"Because it's there" isn't a reason for using Access to
manage your large litigation. But it is a very important
decision that can either become an impediment to winning
your case, or provide you with exciting tools that can
facilitate the entire process. With the right people, the
right timing, and the right expectations, you can do it!
ADDENDUM: ACCESS: WHAT YOU SHOULD KNOW REGARDLESS OF THE
SIZE OF YOUR PROJECT
Here are some general tips for implementing Access in your
firm:
1. Use Access For Small to Medium Projects, not for running
the entire firm.
2. Marketing Hype Says It's "Easy To Use." Yes, if you
stick with the macros and wizards. But you will very soon
outgrow these and then be ready for some serious learning
time.
3. Access Is Very "Forgiving." You can do things improperly
and it won't complain. But down the road it might get back
at you and you won't know why.
4. Access Can Use Data From Many Different Sources. (dBASE,
Oracle, Paradox to name a few.) You can use Access just for
the user interface (screens) and still use the data from
these other sources.
5. Who You Train Is Absolutely Crucial. It's a steep
learning curve so only train those people who want to learn.
6. How You Train Is Important, Too. Don't hand a book to a
secretary or paralegal and think they will learn it in their
spare time. Classes at training centers are a good start.
Then, bring in a consultant to work with them on their own
projects. You get the most for your training dollar this
way.
7. Once Trained, Staff Members Become More "Marketable."
You may need to give them raises to keep them.
8. Welcome Change. If you're not familiar with Microsoft,
you need to know that there will be near-constant
"upgrades." You may love the product just as it is but that
doesn't stop Microsoft from changing it. So, for better or
worse, you will have to keep up because eventually they will
stop selling and/or supporting your version.
9. Expect a Deluge of Requests as soon as one or more staff
members become competent with Access. Word will quickly get
out about these neat databases and soon everyone will want
one.
10. Offer A Training Session on "What Is Access?" so your
staff know when it is called for and when something else
would be a better choice. This session will save time by
preventing staff from beginning Access projects that they
can't handle. Also, consider having only a handful of
people design the tables for each project, and then teach
your staff how to create their own projects/reports with
these tables. Put another way: develop different skill sets
in different people depending on their abilities and
interests.
Copyright 2003 Rachel Levine. All rights reserved.
ABOUT THE AUTHOR
Rachel Levine is an independent Microsoft Access consultant, programmer and trainer. She has been working with databases for 15 years, the last six of which have been dedicated to Access. She has worked on several very large litigations as well as various corporate projects for several large firms. You can contact Rachel via e-mail at cyberyenta@cyberyenta.com or telephone (914-478-1553), and you can visit Levine Consulting on the Web at www.CyberYenta.com/RLevineConsulting.htm .
|
|
|
