Careers

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.

 

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.