eDiscovery Daily Blog
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.