By Ron Friedmann and Jean O’Grady, 1994
An unpublished article circulated to friends of the firm with interest in this topic.

The firm has undertaken several work product database projects since 1983. What sounds like a simple and easy project actually has many difficulties. When we first started in 1989, one of the problems was finding software that could handle the task. With the advent of Windows, advances in full-text engines, faster processors, and cheaper memory, this problem has been solved. The other difficulties remain. This brief history reviews the main work product projects and, in so doing, explains the problems we will face in any future project.

A key element of a successful work product database is that it includes a high percent of the useful work product we have generated. Unfortunately, persuading lawyers to put documents into a database is difficult. Aside from lack of interest, lack of time, and some unwillingness on occasion to share, there is the “not final” problem. A fear expressed by several advocates of work product was that certain documents, either litigation or transactional, might never be “final” and that therefore the associate authors would be reluctant to place them in the “public view” of a work product database. For example, the 100-page brief with lots of good research might never be filed because of a last-minute settlement. The fear was that the author would think that because some small portion was not cite-checked or fully thought out, he/she would withhold from the database.

Our initial answer to this problem was the “vacuum cleaner” approach. By that we mean that we took every document, by year, from every lawyer’s Wilmer-public directory with the idea of putting it in the database. (There was an opt-out system to protect firm-confidential or personal information.) The vacuum cleaner approach has several major problems:

1. There is just too much stuff. Our theory was that with a smart search engine, the good stuff would rise to the top. But it didn’t work out that way. The biggest problem was that some really long outlines from our securities practice seemed to come up in 50% of the searches. This is a function of length and breadth. It does raise the question of the appropriate unit of retrieval, which may not always be a whole document (sections might be more appropriate for longer documents).
2. We did not cull out earlier revisions. Even with a good search engine, the multiple versions all are hits and it is very frustrating to keep seeing the same document. Without document management software, culling out the “final” version is quite hard and time consuming.
3. It is now absolutely clear that full-text alone is not nearly as valuable as full- text with some bibliographic coding. With the volume of documents we had, we either did minimal or no coding.
4. The vacuum cleaner approach does not address the walling-off concern. With all work product in the database, a lawyer walled-off from a matter is at risk of seeing a document from the matter from which he/she is walled off.

We tried the vacuum cleaner approach in 1989 and 1990. After two years of effort, we gave up. Using what we learned on this project, we tried a different approach in 1990-91: Our bankruptcy practice was very busy. The partners running it wanted a tool that would help bring new associates up to speed quickly. We decided to build a work product database. This time, we decided to do it differently:

1. We would include only useful documents that were screened by a lawyer or legal assistant knowledgeable about the practice.
2. We would code each document more carefully and thoroughly. This work was done largely by legal assistants with bankruptcy experience.
3. We included publicly available non-Wilmer documents such as the code, local court rules, and PLI outlines to which we had rights.
4. We had active and vocal support, and some help, from partners and several senior associates.
5. We built the database in Windows, to make it easier to use. Being 1991 or so, we had to give all our bankruptcy lawyers 386 PCS (the 486 didn’t exist then) and Windows software.

By and large, this database was far more successful. Many associates used it. But there were difficulties. First, getting new documents in was a constant struggle. It required regularly harassing secretaries, lawyers, and legal assistants. Second, we were just learning Windows then and there was little other Windows software, so we encountered the many technical problems in setting up Windows and cutting and pasting text from the database to word processing. And third, when the database “champion” was pulled to work on a big client project, the database began dying.

The paradigm though, proved workable. The key elements were dedicated support, lawyer involvement in planning and implementation, easy-to-use software (once Windows issues were resolved), and careful and thoughtful coding. Even with this, it takes effort to create sufficient awareness, especially among those new to the practice, to remember to use the database. We also use this paradigm with reasonable success for our one client-specific database.

There are two reasons we have not focused more effort on work product. First, we thought we would acquire document management software in 1993 but decided not to because we concluded the products were not ready. Our thinking was that with document management on the way, we should just wait a bit because it would then become a lot easier to find and catalog documents for inclusion in a full text databases. Second, we get by without a fully effective firm-wide database through the use of e-mail. Lawyers frequently broad- or narrow-cast messages looking for prior work product or expertise. They generally do receive helpful replies.

Document management software is likely to make building a database much easier. Assuming that lawyers fill in some mandatory information, it will become much easier to find documents worthy of inclusion. Doing so may still require a lot of manual review, but the time for this will be much reduced.