Law Firm Departments

So far in this blog series, we’ve taken a look at the ‘litigation support culture’ circa1980, and we’ve covered how databases were built and used.  We’ve come a long way since then, and in the next posts I’m going to talk a bit about how 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 and here.

Litigators who used databases circa 1980 – for the most part – recognized a significant improvement in efficiencies.  As technology and approaches evolved over time, more efficiencies were realized.

One of the first big changes in how we worked was the use of microfilm.  Paper documents were still photocopied and coded, but microfilm became the preferred mechanism for storing and retrieving documents.  While the technology had been around for quite a long time, the litigation projects I worked on used paper repositories up until the early 1980s, which is when microfilm started to become the standard. This approach offered multiple advantages, the most significant being:

1. It dramatically reduced the amount of space required to store a document collection.  The documents for a large case could be stored in a box or two rather than in a room or two. This also meant that it was reasonable to have multiple copies of a document collection stored in offices convenient for the litigation team, rather than a single, central repository of documents.
2. Attorneys still used central repositories to handle large document pulls, but with microfilm It was faster and easier to retrieve those documents — turnaround time was much better.
3. It preserved the integrity of the document collection.  Once a collection was filmed, pages wouldn’t be lost, shuffled, or damaged.

So, what is microfilm and how does it work?  Micro-reproductions of document pages are stored on reels of film.  Here’s a picture:

Those reels are labeled with the inclusive document number range.  Now — when doing a document pull – instead of locating a box and pulling a document to photocopy, you would locate a reel, thread it on a microfilm reader (see picture above), scroll to the correct frame, and hit a print button.

This approach evolved even further, and we started using microfiche.  The principle was the same, but the film was stored on cards instead of reels:

The cards were stored in sleeves labeled with the inclusive document numbers, and the cards were inserted into a microfiche reader.

Let me point out that microfilm and microfiche are still in use today in many libraries around the country.  Most libraries are no longer ‘filming’ new documents (they’re using imaging technology), but many still have historic collections of newspaper and magazine articles stored on microfilm or microfiche.

Tune in next week — 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.

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.

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.

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.

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.

 

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.

 

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.