Every firm must determine the knowledge strategy projects that are right for it, in light of its own firm strategy, practice management situation and budget. The ideas presented in this white paper are intended as food for thought.

Document Metadata and Auto-Profiling

What are Metadata and Auto-Profiling?

Metadata are additional data saved with a document that give contextual meaning to the document. Common examples of metadata are:

• Document type
• Title
• Author
• Date
• Client & matter

Less common examples of metadata are:

• Industry
• Subject(s)
• Governing law (for contracts)
• Jurisdiction (for litigation documents)
• Judge (for litigation documents)

Auto-profiling involves using automated rules to assign various metadata elements based on document content. Examples of metadata that can be assigned, with varying degrees accuracy, by currently available software are:

• Document type
• Title
• Subject(s)
• Governing law
• Jurisdiction
• Judge

Why Does Metadata Matter?

Reliable metadata facilitates better document searching. For example, a legal research search could be limited to documents of the type "Memo",  "Letter" or "Brief", thereby avoiding hits on agreements or other types of irrelevant documents that may contain the search terms. Or a search for license agreements could be narrowed to a particular industry or governing law.

Metadata also allows other data to be connected. For example, through client/matter linking, the names of the senior lawyers who worked on the matter can be identified for consultation about the document or, in the case of a litigation document, about the judge.

What Are the Sources of Metadata?

The most common source of metadata is the document profile in the document management system. Because the goal is reliable metadata, consideration should be given to the likely accuracy of the information. The profile is typically completed by the first person to work on the document. This may be the most junior lawyer involved, a paralegal, a secretary or a central word processing department. Each of these may have a different approach to completing the required fields.

The most reliable metadata are client/matter information and dates the document was created and last edited. Document type, title and author are typically not reliable. Type and title have little or no bearing on any other action taken with the document, so the answers probably don't matter to the typist. Where multiple lawyers are involved in the document, author will typically be the most junior person, whereas the most senior lawyer who approved the document may be the desirable lawyer to consult.

Another source of metadata is information automatically taken from workflow that has a purpose other than assisting in document categorization. This kind of metadata is more accurate than the manually inserted information discussed above. For example, if documents are created using a word processing macro or template that varies by major document type, the type of macro or template can be used as document type. To accomplish this, custom software would need to be written to pass that information from the macro to the document management profile. That may well be a worthwhile effort to improve the effectiveness of document searching.

If the firm used an electronic workflow system to approve final versions of documents, the names of the approving lawyers could be collected as metadata for the document, thereby readily identifying the best lawyers to consult about it.

While it may seem desirable to ask lawyers to provide document metadata, in practice this rarely works. Even mandatory fields in a document profile may be completed arbitrarily if they have no other effect on the lawyer's work. Except in the case of high volumes of similar documents, secretaries and paralegals generally do not know the subject matter well enough to tag documents accurately, even after training.

What Metadata Categories Should Be Used?

The nature of the firm's practice, its practice group organization and the document population should drive the selection of metadata elements and permitted categories within each element.

For example, document types for one firm could be

• Advice - letters, memos and e-mails containing legal advice
• Contracts - agreements, benefit plans, entity organizational documents (charter, bylaws)
• Formal policies - personnel policies, compliance policies
• Disclosure documents - prospectus, private placement memorandum
• Court papers - motions, briefs
• Discovery documents - interrogatories, deposition questions
• Opinions - formal legal opinions

Document types (categories) for a different firm's practice could be quite different. It is important not to have too many document types. The more different types, the harder it will be to obtain the information accurately, if at all.

Subject matter categories - called a taxonomy in the know-how sharing world - should similarly be driven by the firm's practice, organization and document population. Building a taxonomy from scratch is the best approach, though it also requires the most time. The number of subjects and number of levels should not be too numerous - or too few. A rule of thumb is to have a maximum of 30 subjects and 4 levels. Consideration could also be given to establishing different taxonomies for each practice group. Ideally, the document population, or a random sample, should be tested against these categories to confirm that each category does not include too few or too many documents.

Utilizing a pre-set taxonomy developed outside the firm is the quickest but least desirable approach. A reasonable middle ground would be to start with an internal taxonomy used for a related purpose (such as a paper records file) or possibly an external taxonomy, but modify it based on the firm's practice, organization and document population.

Software is available that uses complex rules to assign some metadata categories, such as document type, subject, governing law, jurisdiction and judge. Each software product works differently and with differing degrees of success.

Metadata can also be gathered from other firm know-how sources. For example, information about the client industry and about the type of matter could be taken from the firm's database described below under "Matters and Lawyer Experience Database". That would enable a search on merger agreements to be narrowed to a specific industry or matter type.

Security and Access

Who can see which documents in a work product retrieval system must be decided. Some products apply the security assigned to each document by the document management system. This may or may not produce a desirable result. The default DMS security setting will likely be the most common one in the document population. Consideration should be given to whether this is too broad or too narrow. For example, if most documents have full security, so only the author can view them, the search population may be unreasonably small. If most documents have no security, confidential or sensitive documents may be made available to users who should not see them.

Other software products may apply security for searchable documents based on settings established for the client/matter to which the document is assigned. In those cases, consideration needs to be given to whether those settings are appropriate for all documents in the matter.

Given the sensitivities, the appropriate balance between security and access should be approved by firm management. Each firm will need to arrive at its own balance.

E-Mail Categorization and E-Filing

Law firms have recognized that e-mail has for some time now taken over some of the functions of word processed documents. Firm filing and retrieval policies and systems for e-mail, however, lag those for word processed documents. Software aids are catching up, though.

E-mail Is Different

E-mail differs in some respects from word processed documents. For example, there are many more non-substantive e-mails than documents. Also, an e-mail may be non-substantive but contain a substantive attachment. Firm policies regarding filing and retention of e-mail may not be as evolved, and those policies may not be as well-observed, as policies for filing and retention of word processed documents.

Software Varies Widely

The most effective approach for software-aided e-mail filing is still evolving, as evidenced by the variety of product features.

Some software aids are focused mainly on archiving, in other words, moving messages out of the e-mail system into an archive database, which may not be as immediately accessible as the user's primary e-mailbox. The focus of archiving is improving performance and working around the storage limits of Microsoft Outlook.

Other software does focus on categorizing and filing e-mail, such as by

• client/matter
• subject
• industry
• potentially other categories used by the work product retrieval system for documents

Even the e-filing products vary in how they accomplish e-mail filing. Some move it to the document management system and create a profile, which is automated to varying degrees. This approach may not be as elegant as other solutions, which move e-mail to a stand-alone database (while still applying automatically-generated metadata).

Challenges Remain

Challenges remain for firms and software developers. For example, a firm must decide which e-mails to e-file in the work product retrieval system. Leaving the question to individual lawyer decisions seems inadvisable. If there is a firm-wide policy, such as mandatory filing of any e-mail containing substantive legal advice, how does the firm ensure compliance? Will lawyers resist complying with the policy to avoid having their e-mail scrutinized and potentially criticized by others? If instead all e-mail is automatically captured, will non-substantive e-mail overwhelm the system or the users?

If the firm policy requires selective filing of e-mail (such as all substantive e-mail), how can the process be made the easiest for lawyers, so as to maximize compliance? The available options will depend on the software selected. One approach is to create an easy manual button on the e-mail panel for linking client/matter numbers to the e-mail (which also results in e-filing). Still, the lawyer must remember to do this before (or possibly after) sending. Another method is to allow dragging and dropping the e-mail into a matter folder that the lawyer may also use as his or her personal e-mail organizing system. E-mail in the matter folder would automatically also be e-filed. Yet another approach is for a prompt box to be automatically triggered at each send. Such an approach may be quite desirable if the prompt box suggests an appropriate category or categories based on a prior e-mail to the recipient or based on other attributes.

Another challenge is the handling of e-mail attachments. One approach is to file the attachment with the accompanying e-mail. The other is to file the attachment separately, in which case a method to categorize the attachment must be devised. In either case, consideration must be given to whether the attachment is a duplicate of one in the document management system and, if so, whether potentially different categorization of two identical documents is desirable or even acceptable.

Finally, security and access policies for filed e-mail must considered. The considerations involve the same balancing of lawyer privacy/client sensitivity against availability of content for searching, as discussed above in "Security and Access" in the discussion of "Document Metadata and Auto-Profiling". Once access rules are developed, consideration must be given to the ability of the chosen software product to implement them.

Enterprise Search

What Is Enterprise Search?

Enterprise search is the coupling of a search engine with software connectors to various firm databases to allow seamless free-text (and possibly category-based) searching across all the databases. The document management system population typically forms the foundation database.

Other databases that may be considered for searching include:

• Database of filed e-mails (if separate from DMS)
• Standard forms library
• Training materials
• Matters and experience database (or other marketing database)
• Contact management (CRM) database
• Conflicts management system
• Intranet
• OCR of paper records
• Matter descriptions from billing system
• Billing data (limited access, such as partners only)
• Work description in lawyer time entries
• HR system (limited to biographical information, such as schools attended, professional memberships, areas of expertise, etc.)
• Special collections - for example, practice group precedent files (may need to be OCR-ed)

Issues to Consider

The most important consideration in building an enterprise search system is the nature of the questions the system is expected to answer. "If we build it, they will come" is not a good approach. Areas of interest should be gathered from focus group discussions with lawyers in different practice areas. Examples of possible cross-database searches can be given to start the discussion and catalyze their thinking.

The next consideration, which is related to the first, is the number of firm databases the system will search. It is best to start with a small number of data collections - those at the heart of the questions to be answered - and add more over time. Some data collections will require more effort than others to prepare for inclusion in the enterprise search system. For example, searching of filed e-mail may require policy decisions about security and access. Accessing specialized firm data collections may require development of customized software connectors.

Enterprise search can be a big project, so vendor selection is important, including the software provider and the systems integrator. These selections should not be finalized, however, until the firm has identified the questions to be answered by the system and at least the initial data collections to search.

Before the enterprise search system is made available to the entire firm, conduct tests with small groups of users. One purpose of the tests is to verify user acceptance of the design. Another purpose is to discover, to the extent possible, the unexpected sensitive documents that will be found, so that access adjustments can be made. Firm management should also be advised that, despite this kind of vetting, some sensitive documents will inevitably turn up in searches as the system is used in its early stages.

Matters and Lawyer Experience Database

What Is an Experience Database?

An experience database is a system to track and retrieve the firm's experience in working on particular matters and its lawyers' expertise in particular subjects. For example, such a system could answer, or lead to a person who could answer, the following kinds of questions:

• What matters of a particular type or in a particular industry has the firm worked on? This information is useful for pitching business and finding comparable matters for benchmarking fee estimates and alternative fee arrangements. It could also be useful for finding relevant precedent documents.
• Which lawyers have worked on this type of matter? This is useful for staffing (and presenting potential staffing for pitches), as well as identifying lawyers with whom to consult when questions arise.
• What do our lawyers think of this particular judge? This can be very helpful information for the litigators appearing before that judge.
• Who is the firm's internal expert on a particular subject? If the expertise information is sufficiently granular, this can be an efficient way to resolve a legal issue.

How Is an Experience Database Constructed?

The primary driver for a firm experience system is manual input of the matter description and work done. The matter description at the time of intake in the billing system is most likely not adequate. It will be too abbreviated and general. A questionnaire system (electronic or paper) operating after the matter is completed (triggered by billing, perhaps) and with appropriate follow-up, would be one way to gather this information. A variation would be to have a paralegal complete the questionnaire based on a phone call to the partner or senior associate.

Another approach - after-matter review meetings - carries greater benefits, but will be more difficult to implement because it requires lawyers to change how they work. The approach requires holding a meeting after completion of the matter with the lawyers who worked on it. The meeting should be designed to serve several purposes. A primary agenda would be to discuss lessons learned, both as to substantive legal matters and client relations and other matter management issues. That aspect would serve as a mentoring process and could improve associate morale. Another agenda would be to identify substantive legal issues addressed in the matter. A final purpose of the meeting would be to generate a description of the matter, preferably a polished version for external use in pitch books and a longer internal version that identified special considerations about the matter. A recording secretary, such as a paralegal, would take notes of the legal and other special issues identified and the matter descriptions, for inclusion in the experience database.

Lawyer expertise in particular subjects can be obtained by asking them to respond to questionnaires, by linking their names to the legal issues identified in the after-matter review meetings described in the previous paragraph or by determining whether they billed above a certain number of hours to a matter for which documents mentioning that legal issue were prepared. The latter method, which depends on software features, may work for some firms, but probably will not work well for firms with large lawyer teams on their matters.

A few specialized software products exist to assist in the collection and retrieval of information for a firm experience system. Product features vary widely. A home-grown database system may also work well. Regardless of the software employed, the key to success is the quality of the matter description and related information.

Portal

What Is a Portal?

A portal is a web interface in which various firm systems and other sub-windows (called web parts) are displayed, generally in a format customized for the individual user. For example, a portal might contain

• a sub-window for the document management system showing a list of the user's recently accessed documents, or those for matters on which the user is currently working,
• news clips about the user's clients,
• billing information about a partner's clients, and
• a matter sub-window, showing documents and e-mail for that matter.

How Is a Portal Implemented?

A portal requires software that can display the sub-windows in a web browser, together with software links (called connectors) to the various systems that comprise the sub-windows. Connectors to popular systems, such as the major document management and e-mail software, will have already been developed for use on a plug-in basis. Connectors to more specialized firm systems will need to be custom-written.

A portal is more of a delivery system that's user-friendly than it is a knowledge management system that finds information. Nevertheless, a portal can promote the firm's knowledge management efforts by making its existing knowledge management systems more visible and easier to access.

Focus groups with lawyers in a variety of practice areas will make the portal's presentation most useful to the firm's lawyers. Only a minority of lawyers will bother to customize their portal home page further than the firm default.

Questions?

We welcome your questions. Please see our Contact Us page.