Posts By :

Jane Gennarelli

Guide for Making the Most of LegalTech: eDiscovery Trends

Editor’s Note: Believe it or not, LegalTech® New York (LTNY) starts in one week. The show can be overwhelming if you’re not prepared. A couple of weeks ago, Monica Bay wrote a terrific article in Law Technology News (Tips for Newbies to Survive LegalTech New York) which provides suggestions from several show veterans on how to get the most out of the show. That reminded me that Jane Gennarelli wrote a post on this blog three years ago with her own suggestions, so I’ve revisited it below. For best results, check out both articles and make your game plan from there! 🙂

It’s that time of year… LegalTech® New York is right around the corner. People are talking about it, making plans to get together, scheduling demos and meetings, and deciding which parties to attend. Newbies to the show are excited to go. More seasoned attendees are looking forward to seeing peers. It’s a great time to catch up with people and it offers a great opportunity to keep abreast of new industry trends and technology advancements.

Is there a downside? Well, yes, there is. Attending the show costs money (travel expenses, lost billings, or both). And more significantly, it eats up one of our scarcest resources: time. Some years I’ve questioned whether it was worth it. Other years, it’s been obviously valuable. Interestingly, the difference has not had anything to do with the show itself, but rather with my approach to it. So let me suggest an approach for making the most out of your next LegalTech show.

  1. Establish one or two primary objectives: Determine what you want to accomplish or what you want to learn, and make those your objectives. For example, maybe you don’t have experience with predictive coding and want to learn more about it. Or maybe it’s been awhile since you’ve looked at document review tools and it’s time to re-evaluate them. Identify specific objectives to focus on.
  2. Identify conference sessions to attend: Look at the conference schedule and identify sessions aimed at the objectives you’ve established. Put them on your calendar.
  3. Identify vendors with products and/or services aimed at your areas of interest: Review the exhibitor list, go to vendor web sites, and make a list of vendors of interest. Identify the exhibit booths you’d like to visit, and identify the vendors with whom you’d like to meet.
  4. Schedule demos and meetings: To ensure you meet your objectives, schedule meetings and/or demos with a few vendors.
  5. Prepare lists of questions: You will get the most out of meetings/demos with vendors if you are armed with a list of specific questions. For each of your objectives, identify the questions you should be asking.
  6. Keep good records: At the show, take good notes and collect contact information. You will be meeting a lot of people and it will be very difficult to remember everything you’ve learned if you’re not taking good notes!
  7. Take advantage of the networking opportunities: Get together with peers and talk about what they are doing, what tools they are using, and what approaches they’ve implemented. Introduce yourself to people you don’t know. Casual conversations in social situations can be invaluable!
  8. Commit to reporting on what you’ve learned: Before the show, commit to preparing a report on your findings. You are more likely to stay focused on your objectives if you’ve committed to reporting on them.

If you haven’t approached LegalTech with this type of plan yet, you may be surprised at what a difference it can make! Do the up-front leg work, enjoy the show, and make it a good use of your time!

So, what do you think? Are you ready for LegalTech? Please share any comments you might have or if you’d like to know more about a particular topic.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscoveryDaily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – How things evolved, part 3

So far in this blog series, we’ve taken a look at the ‘litigation support culture’ circa 1980, and we’ve covered how databases were built and used.  We’ve come a long way since then, and in the past couple of weeks we’ve discussed how things have evolved — we’ll continue that this week. First, though, If you missed the earlier posts in this series, they can be found here, here, here, here, here, here, here, here, here, here and here.

In the past couple of weeks we’ve talked about the form in which document collections were stored and the evolution – first in paper form, then on microfilm, then microfiche, and then as digital images.  Database content has evolved too.  Early databases included coded information only.  In the mid 1980’s, litigation support professionals starting thinking about and talking about OCR (optical character recognition) technology, mostly because one of the main-stream litigation support vendors promoted the advantages of full-text databases.

The primary advantage was, of course, the availability of all words on a document for searching.  There was a price-tag though, because the starting point was still paper.  Text was captured in an OCR scanning process.  Like image technology, full-text took a while to catch on in our industry.  The biggest hurdle initially was a lack of confidence in the results – with good reason.  At the time, searching the internet wasn’t mainstream, so the average litigation team member wasn’t comfortable with employing a less-than-rigid search method.

In addition, search technology was less advanced than it is today, so there was a greater burden on the user to get a search right.  And, OCR technology wasn’t as advanced either, so there were a lot of errors in the scanning process – errors that affected search results. Over time, however, these things changed.  Average business people became more and more comfortable searching text (thanks in large part to Google); search technology advanced; and OCR technology advanced.

Eventually, including full-text in a database became the norm, and even started replacing coded information.  Another factor that contributed to the evolution of full-text was the cost to store data.  It used to be expensive.  I remember sitting in meetings where attorneys debated on things like using abbreviations and punctuation in databases because of the expense of storage – they looked for every way they could to cut down on the data that was stored.  As storage costs went down over the years, it became easier to justify including full-text in databases.

These changes — databases that included images and full-text, coupled with advanced search technology – made a huge change in how litigation databases were used.  Databases were no longer a ‘back-office’ tool – they were used directly by attorneys, and they provided attorneys with very, very fast access to their documents.  By the mid 1990’s litigation databases were not only main stream, but they were regularly portable.  Not only did attorneys have almost-immediate access to their documents – they had that access even when not in the office.

This brings us up to the 1990’s, at which point electronic discovery quickly emerged as the next big advancement.  I won’t cover the evolution of it in this series… CloudNine has documented that well here in its eDiscovery Daily Blog.

This post concludes the Throwback Thursday blog series. I hope you enjoyed this look back at the way things used to be in our industry!

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Blog Throwback Thursdays – How things evolved, Part 2

So far in this blog series, we’ve taken a look at the ‘litigation support culture’ circa 1980, and we’ve covered how databases were built and used.  We’ve come a long way since then, and in last week’s blog, we started discussing how things have evolved.  In the next posts, we’ll continue discussion of things evolved, but first, if you missed the earlier posts in this series, they can be found here, here, here, here, here, here, here, here, here, and here.

Last week, I described the use of microfilm and microfiche to store document collections.  As most of you know, the next step in the evolution process was a move to storing documents as images.

This was a huge step in the world of litigation support, and honestly it was long overdue when it finally became adopted as a standard.  Like so many advancements, it was ‘looked at’ and ‘talked about’ for years before it became the norm.  One of the most significant hurdles was simply cost:  while the cost to scan documents to create images wasn’t much different than the costs to photocopy or film, image viewing technology was expensive.  Firms did not already have this technology, and corporate clients were not willing to bear the cost.  Eventually, however, it caught on.  By the late 1980’s more and more litigation teams were building databases with images.

There were other changes happening that helped this along – a couple of which meant using images only made sense:

  1. The use of computers in general was becoming more widespread.  Computers were no longer only used by large companies.  Small and mid-sized companies were using them.  PCs were introduced to the world so large main-frame computers and mini computers were not the only option. Desktop computers were becoming widespread.
  2. Because the use of computers was growing, more and more commercial software products were available, including commercial litigation support products.  Two of the first popular commercial products were Inmagic and BRS Search.

Because of these changes, technology use in law firms grew.  Law firms were buying computers for use by attorneys and paralegals.  Law firms started hiring IT staff.  Law firms started hiring litigation support professionals and buying litigation support software.  In short, law firms were developing internal resources to build and maintain databases.  They were creating an infrastructure that could support the use of images.

Including images in litigation support databases caused another shift in the way databases were used:  because the documents themselves were immediately available in a database, databases were being used more and more often directly by attorneys.  They were no longer a ‘back-office’ function.  For many years, it was common for law firms to have ‘walk-up’ litigation support stations, but these ‘walk-up’ stations were often used by attorneys, and eventually it became normal to see a computer on every desk in a law firm.

Tune in next week and we’ll continue discussion of how the litigation world circa 1980 evolved and got to where it is today.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – How Databases Were Used, Circa Early 1980s, Part 5

So far in this blog series, we’ve taken a look at the ‘litigation support culture’ in the late 1970’s and early 1980’s, we’ve covered how databases were built, and we started discussing how databases were used.  We’re going to continue that in this post.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here, here, here, here and here.

In last week’s post, we covered searching a database.  As I mentioned, searches were typically done by a junior level litigation team member who was trained to use the search engine.  Search results were printed on thermal paper, and that paper was flattened, folded accordion style, and given to a senior attorney to review – with the goal of identifying the documents he or she would like to see.  Those printouts included information that was recorded by a coder for each document.  A typical database record on a printout might look like this:

DocNo: PL00004568 – 4572

DocDate: 08/15/72

DocType: LETTER

Title: 556 Specifications

Characteristics: ANNOTATED; NO SIGNATURE

Author: Jackson-P

Author Org: ABC Inc.

Recipient: Parker-T

Recipient Org: XYZ Corp.

Copied: Franco-W; Hopkins-R

Copied Org: ABC Inc.

Mentioned: Phillips-K; Andrews-C

Subjects: A122 Widget 556; C320 Instructions

Contents: This letter incudes specifications for product 556 and requests confirmation that it meets requirements.

Source: ABC-Parker

The attorney reviewing the printout would determine (based on the coded information) which documents to review – checking those off with a pen.

The marked up printout was delivered to the archive librarian for ‘pulling’.  We NEVER turned over the original (from the archive’s ‘original working copy’).  Rather, an archive clerk worked with the printout, locating boxes that included checked documents, and locating the documents within those boxes. The clerk made a photocopy of each document, returned the originals to their boxes, and placed the photocopies in a second box.  When the ‘document pull’ was complete, a QC clerk verified the copies against the printout to ensure nothing was missed, and then the copies were delivered to the attorney.

In last week’s post, I mentioned how long it took for a database to get built.  Once the database was available for use, retrievals were slow, by today’s standards.  Depending on the number of documents to be pulled, it could take days for an attorney to get a stack of documents back to review.  While that would be unacceptable today, it was a huge improvement over the alternative at the time – which was to flip through an entire document collection eyeballing every page looking for documents of interest.  For example, when preparing for a deposition, a team of paralegals would get to work going through boxes of documents and eyeballing every page looking for the deponent’s name.

Working with a database then was – by today’s standards – done at a snail’s pace.  But the time savings at the time were significant.  And the search results were usually more thorough.  On one project I managed, just as the database loading was completed, an attorney called me to say he was preparing for a deposition and had his paralegals manually review the collection looking for the deponent’s name.  They spent a week doing it and found under 200 documents. He was uncomfortable with those results.  I told him the database was almost available – we just had to do some testing – but I could do a search for him.  I did that while he waited on the phone and quickly reported back to him that the database search found almost twice as many documents.  We delivered the documents to him within a couple of days.

Tune in next week and we’ll cover how the litigation world circa 1980 evolved and got to where it is today.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – How Databases Were Used, Circa Early 1980s, Part 4

So far in this blog series, we’ve taken a look at the ‘litigation support culture’ in the late 1970’s and early 1980’s, and we’ve covered how a database was built.  We’re going to move on to discuss how those databases were used.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here, here, here and here.

After coding and keying, data from magnetic tapes was loaded into a database, usually housed on a vendor’s timeshare computer.  This was before business people had computers on their desks, so litigation teams leased computer terminals – often called “dumb terminals”.  The picture above is of a Texas Instruments Silent 700 terminal – which was the standard for use by litigators.  This photo was taken at the Texas State Historical Museum.

These terminals were portable and came housed in a hard plastic case with a handle.  By today’s standards, they were not “compact”.  They were in fact quite heavy and not as easy to tote around as the laptops and tablets of today.  As you can see, there’s no screen.  You inserted a roll of thermal paper which ‘spit out’ search results.  And, as you can see, you accessed the mainframe using a standard telephone.  The phone’s handset was inserted into an acoustic coupler on the terminal, and you dialed the computer’s phone number for a connection.  You’re probably thinking that retrievals were pretty slow over phone lines…  yes and no.  Certainly response time wasn’t at the level that it typically is today, but the only thing being transmitted in search sessions was data.  There were no images.  So retrievals weren’t as slow as you might expect.

Searches were done using very ‘precise’ syntax.  You asked the database for information, and it collected precisely what you asked for.  There weren’t fuzzy searches, synonym searches, and so on.  The only real search that provided flexibility was stem searching.  You could, for example, search for “integrat*” and retrieve variations such as “integrate”, integrates”, “integrated” and “integration”.  The most commonly used search engines required that you start a search with a command (like “find”, “sort”, or “print”).  If you were doing a “find” command, that was followed by the field in which you wanted to search, an equal sign, and the word you were searching for.  To search for all documents authored by John Smith, your command might look like:

Find Auth=Smith-J*

The database responded by telling you how many records it found that matched your criteria.  Usually the next step was to sort the results (often by date or document number), and then print the results – that is, print the information that was coded for each record.  Keep in mind, “prints” were on a continuous roll of thermal paper spit out by the machine.  More often than not, searches were done by junior litigation team members and results were provided to a senior attorney to review.  So the thermal paper roll with the results was usually flattened and folded accordion-style to make reviews easier.

In next week’s post, we’ll discuss retrieval of the actual documents.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – How Databases Were Built, Circa Early 1980s, Part 3

In the last couple of Throwback Thursday posts we covered the first stages in a database-building project (circa 1980), including designing and planning a database, preparing for a project, establishing an archive, coding and qc, and production status record keeping. The next steps are described here.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here, here and here.

Batching and Keying: After coding and quality control, the next step was batching the coding forms. An archive librarian removed completed coding forms from folders, ‘batched them into groups, updated the activity log, and packaged the forms for shipping.  The packaged forms were shipped off to a keypunch vendor – usually located outside of the U.S.  The vendor I worked for used a keying company located in Jamaica. The vendor keyed the information from the forms to magnetic computer tapes (see the image above). Those tapes and the coding forms were then shipped back to the coding vendor.  Depending on the size of the batch, keying could take days.  And there was shipping time on each end.  It could take a week or more to get data back for large batches.

Data Loading:  As I mentioned in an earlier post, for the most part, databases ‘lived’ on a vendor’s mainframe computer and were accessed by clients using computer terminals.  When the vendor received tapes from a keypunch vendor, the next step was loading to its mainframe computer.

End-User Training:  While this still happens today, training was a much bigger deal back in the day.  The normal business person was not computer literate – most of our clients had never used a computer before.  Training usually took a day or two, and it involved educating users on how to do searches, on how databases were structured, and on how data was coded in a specific database.

A word on schedules:  Today we live in a world where everything is done almost immediately.  Once documents are collected, processed and loaded (all of which can happen pretty quickly), documents are available for searching.  With initial databases, it usually took months before the first documents were available for searching.  Every step in the process (photocopying, archive establishment, coding, qc, batching, and keying ) took days or weeks.  Of course we didn’t wait for a step to be completed for all the documents before starting the next step, but even so, it was a long time before the first documents were available for searching.

A word on backups:  In the electronic world we live in today, we rely on computer backups…  and we do them frequently.  Even if there’s a significant technical problem, we can usually go to a fairly recent backup without too much work being lost.  This was always a concern with initial database projects.  Our law firm clients usually didn’t send us the ‘original working copy’ of a document collection.  They had a second copy made for the database work.  But a lot of work was done and a lot of time elapsed between delivery of those documents and data being available in the database.  Problems like fire, flooding, and packages lost in shipping could mean lost work.  And those things happened on occasion.

In next week’s post, we’ll take a look at how databases were used, and how searching and document retrieval worked.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Blog Throwback Thursdays – How Databases Were Built, Circa Early 1980s, Part 2

The Throwback Thursday blog two weeks ago included discussion of the first stages in a database-building project (circa 1980), including designing and planning a database, and preparing for a project. The next steps are described here.  But first, if you missed the earlier posts in this series, they can be found here, here, here, here and here.

Establishing an Archive: Litigation teams shipped paper documents to be coded to a service provider, and the service provider’s first step was ‘logging documents in’ and establishing a project archive. Pages were numbered (if that hadn’t already been done) and put into sequentially numbered file folders, each bearing a label with the document number range.  Those files were placed into boxes, which were also sequentially numbered, each of which had a big label on the front with the range of inclusive files, and the range of inclusive document numbers.

Logs were created that were used to track a folder’s progress through the project (those logs also meant we could locate any document at any time, because the log told us where the document was at any point in time).  Here are sample log entries for a few folders of documents:

Note, this sample is a little misleading:  logs were filled in by hand, by an archive librarian.

Coding and QC: Folders of documents were distributed to ‘coders’ who recorded information for each document – using a pencil and paper coding form that had pre-printed field names and spaces for recording information by hand.  When a coder finished coding all the documents in a folder, the coding forms were put in the front of the folder, the folder was turned back into the archive, and the next folder was checked out.  The same process was used for qc (quality control) – the documents and coding forms were reviewed by a second person to ensure that the coding was correct and that nothing was missed.

As project managers, we kept very detailed records on progress so that we could monitor where things stood with regard to schedule and budget.  At the end of every workday, each coder and qcer recorded the number of hours worked that day and the number of documents and pages completed in that day.  An archive librarian compiled these statistics for the entire coding and qc staff, and on a daily basis we calculated the group’s coding and qc rates and looked at documents / pages completed and remaining so that we could make adjustments if we were getting off schedule.

In next week’s post, we’ll look at the next steps in a database-building project.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Blog Throwback Thursdays – How Databases Were Built, Circa Early 1980s, Part 1

 

In the late 1970s and early 1980s, very few law firms had internal litigation support resources:  firms did not have litigation support staff or technology.  In 1985, I was offered a litigation support position at a major New York City law firm (which I didn’t accept),,, that’s about when large firms began developing internal litigation support capabilities.  Up until then, most litigation teams relied on vendor services and tools, and more often than not litigation team attorneys were directly involved in working with vendors to design and build databases. In 1980 I took a project management position with a vendor, responsible for overseeing database-building projects. In the next few blog posts, I’m going to describe a typical project and how things worked.

The Vendor Selection Process: This of course was not a ‘step in the project’ – it was part of the sales process. It’s worth mentioning here though, because this was a very big deal, on every project. Because databases were only built for the huge, bet-your-company cases, every project was a big project. For any given project, a vendor would receive a Request for Proposal, which usually required a voluminous, detailed response.

Database Design and Planning: We often spent days in meetings with attorneys designing and planning a database.  Back then, full text wasn’t included in databases and images weren’t included in databases.  That meant that the information that was “coded” for a document was very, very important — It was the only thing in the database.  We needed to learn about a case, learn about the documents, and find out how the attorneys expected to use the documents – this was necessary so that we could advise litigation teams on a coding scheme that would meet their needs.  Remember, this was back before PCs. Back before the Internet. Back before Google. Business people — as a rule — did not understand databases or searching. We, as vendors and consultants needed to be educators, and we needed to advise our attorney clients and recommend – on a case-by-case basis — a design that would meet their needs.

Project Preparation: Sometimes we did projects at our vendor facility, and other times clients requested that we establish a ‘coding operation’ at their site. In either case, we needed to assemble a team of coders. These were usually temporary employees hired for a specific project. Since all the cases we did were big cases, the teams were often substantial. It wasn’t at all unusual to start with a team of 50 or more. The largest project I worked on used a coding team of over 1,000. Of course there were other preparation tasks, but assembling the coding team was the most time consuming. When ever possible, we used people from prior projects, but inevitably, project managers spent a lot of time interviewing candidates for coding positions on every new project.

In next week’s post, we’ll talk more about how a coding project worked.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Throwback Thursdays – The Way We Worked, circa 1980

 

In the late 1970s and early 1980s, the business world looked very different than it does today, and the field of litigation support looked very different than it does today.  Let me paint a picture for you…

  • Mainframe and mini computers were in use in many large and some mid-sized businesses.  They were, however, ‘back-office’ functions.  You didn’t see computers on office desks.  A few desks did have computer terminals, but not many. Disk drives with a capacity measured in the low hundreds of megabytes were the size of washing machines.
  • Although precursors to the internet were in early stages, only ‘computer geeks’ knew about it (and there weren’t that many computer geeks).
  • For the most part, law firms – even very large firms – did not have internal litigation support database tools.  Litigation databases were stored and accessed on the mainframe computers of service providers, which offered ‘time-share’ services.  Typically, those service providers charged a monthly storage fee based on the size of a database, and a per-hour charge for usage.
  • The timeshare databases were accessed with computer terminals – also called ‘dumb’ terminals.  Those terminals did not have screens.  Rather, you inserted a roll of thermal paper, which was ‘spit-out’ with search results (you always needed an ample supply of paper rolls so you weren’t in a bind when the paper ran out during a search session).  You hooked a telephone receiver to an acoustic coupler on the terminal, dialed the computer’s phone number, waited for the high-pitched, scratchy screech that indicated a successful connection, and then queried the database.
  • Databases consisted primarily of “coded” information like dates, authors, recipients, titles, and so on.  Many databases included ‘subject coding’.  There were no images included in litigation databases back then, and including full text didn’t get legs in the litigation support world until the mid to late 1980s.
  • Database search engines did not provide WYSIWYG interfaces or menu options.  You entered precise search commands like “Find Author=Smith-JA and Type=Letter”.
  • Most law firms did not have litigation support professionals on staff.  That work was handled by service providers.
  • Those service providers offered, for the most part, document coding services.  There were only a handful of service providers, and those providers offered services nationally.  When I took my first vendor job (in 1980), we had 5 main competitors and found ourselves all bidding on the same jobs.  The litigation support community was small, and we pretty much all knew each other.
  • No one, and I mean NO ONE, outside of our world understood what we did for a living.  On more than one occasion I heard my mother proudly explaining to a friend that I was a computer programmer.

And that’s how it was, back when I first started in this field.  In the posts to come, I’m going to give more detail on some of these points as we move on to discuss how databases were built, and how searching / retrieval worked.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

eDiscovery Professional Profile: Do you know Cheryl Garner?

 

Cheryl Garner is the Practice Support Manager at Manning & Kass, Ellrod, Ramirez, Trester LLP – a 150 attorney law firm with six offices in the U.S. Cheryl is located in the firm’s main office in Los Angeles, but has firm-wide responsibility. She joined the firm in December 2012, after a long and diverse career in the legal field.

As Practice Support Manager, Cheryl is responsible for litigation support, paralegal staff, the Docket Department, and the Workers Compensation Hearing Representatives. She spends most of her time coordinating the work of those departments, reaching out to attorneys to ensure they have the support they need, marketing the services of the departments for which she is responsible, and educating attorneys regarding best practices and making optimal use of the technology available to them.  She describes herself as a ‘Jack of all trades’ and often steps in with rolled-up sleeves to complete tasks alongside team members. She also directly handles firm-wide litigation support and eDiscovery, working closely with service providers that process data and provide hosting platforms for large cases.

Cheryl’s first legal position was with the US Attorneys office in Chicago.  She was a member of a word processing pool for the civil and criminal teams. From there she went to work for the American Bar Association as a word processing operator, and later worked in law firms as a legal secretary and word processing operator.  As technology advanced, Cheryl recognized that opportunities in word processing would diminish, and she developed a plan for her future.  While working full-time, she completed her undergraduate studies in 2000 and in 2002 she completed an ABA-approved paralegal program.  Armed with a background that included hands-on government and law firm experience, as well as paralegal and technology experience, career opportunities broadened.  Up until 2008 she worked for large law firms providing secretarial, paralegal, technology, and trial support.  In 2008 when she moved to a smaller firm, she soon recognized it was the perfect fit for her at that stage of her career. She believes that the experience she got at the smaller firms after working primarily in larger firms has been invaluable.

In 2012, Cheryl joined Manning & Kass as Practice Support Manager, a recently created position.  The position was still in its infancy when Cheryl came on board, and she saw this as a logical progression in her career.  Cheryl enjoys her work because it incorporates – and requires – the skills she has honed and the interaction she enjoys.  The firm’s structure, having paralegals report to Practice Support, increases opportunities to introduce litigation technology to the litigation teams.  It’s a model that works well for Cheryl.

When asked about her greatest professional accomplishment, Cheryl quickly answered “Getting to where I am now in my career”.  Through hard work, foresight of the use of law firm technology, and education, Cheryl planned and crafted a career that she is proud of, one that she is good at, and one that she thoroughly enjoys.

Throughout her career, Cheryl has been active in professional organizations. While still a paralegal student, Cheryl joined the Los Angeles Paralegal Association (LAPA). Later, she sat on LAPA’s Board of Directors and was Chair of the Litigation Committee.  She is still a member today.  She is also a member of NALA (National Association of Legal Assistants), and recently earned the Advanced Certified Paralegal (ACP) designation in discovery.  She is a member of ACEDS (Association of Certified E-Discovery Specialists) and plans to sit for the CEDS certification exam in the near future.

Cheryl is also an instructor in the technology track of the ABA-approved paralegal program at California State University Los Angeles (CSULA).  Since 2011 she has taught the introductory course Law Office Technology, and more recently, Trial Technology.  She will teach Applied Technology in the Fall of 2014. Cheryl enjoys teaching because it offers her an opportunity to equip paralegals entering the field with the legal technology foundation they will need to succeed as legal professionals.

Cheryl is originally from Chicago, Illinois and started her professional career there.  She moved to Los Angeles 22 years ago with her son, who today also works in the legal industry.  While her work at Manning & Kass and teaching at CSULA take up most of her time, Cheryl finds time to enjoy ‘Chicago Style Stepping’, an urban dance that originated in Chicago and is similar in movements to’ West Coast Swing’ and Lindy Hop.  Cheryl travels to different cities to attend dancing events.  There’s a lot of camaraderie among attendees from different cities, but the dance has recently re-emerged in popularity as a competitive dance, providing attendees an opportunity to showcase stylings from their region of the country.  Although Cheryl hasn’t competed yet, she keeps the possibility open for the future.  Jazz and other styles of music are important to Cheryl and she often attends local jazz concerts and art events around Los Angles.  She’s currently looking forward to a cruise she’s planning with her sister, to an island ‘to be determined’.

Please let us know if there are eDiscovery topics you’d like to see us cover in eDiscoveryDaily.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine Discovery. eDiscoveryDaily is made available by CloudNine Discovery solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscoveryDaily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.