Once a firm decides on a knowledge strategy project to pursue, follow these steps to bring it to a successful conclusion.

This white paper discusses important principles for the people and planning stages of the project, the system design and system use.

People and Planning

Define the Project Scope

It may seem obvious, but too often the step of defining the project scope is overlooked or taken for granted. The following information should be included in the project definition:

• the goal,
• how the project aligns with the firm's strategic objectives, and
• a budget.

The project definition should be written and circulated among the project leaders (see below), initially for comments and when final, for reference.

Starting with an agreed project definition minimizes miscommunication about what the team is working on and can aid in preventing scope creep. If during the project the team agrees the project definition needs to change, those changes should also be written and the revised definition recirculated. Any necessary approvals of the budget for the revised project should also be sought before proceeding.

Recognize It's a People and Process Project

Even if the project will employ software as part of - even the main part - of its solution, the project should not be treated as a software project. The project will almost surely involve considering how the firm's lawyers can be persuaded to work with the software, what practice information the software will require in order to produce results the lawyers will consider useful, how to collect that information, and how to change the way the lawyers work or interact in order to make the project achieve its best results.

Consider the Type of Knowledge the Project Involves

The project will take different forms depending whether the knowledge involved is tacit or documentable (explicit). Tacit knowledge is know-how in a lawyer's brain that cannot readily be reduced to written form, such as expertise in a particular subject. Documentable (explicit) knowledge can be directly recorded once it is accessed, such as an accurate long-form description of a matter.

Each type of knowledge calls for a different approach. For example, compare improving practice group meetings to creating a system to capture information about matters for use in future pitches.

Improving practice group meetings is a tacit knowledge project that focuses on improving how lawyers interact at meetings in order to enhance sharing of know-how through teaching, to identify and analyze current issues and to improve lawyer communication by showing who to consult on various issues.

Creating a matter information system is a documentable knowledge project that focuses on how to capture the needed information in a realistic manner, such as through after-matter review meetings, and how best to store and retrieve the information.

Senior and Respected Lawyers Must Lead the Effort

Most knowledge strategy projects will require lawyers to change the way they work. Persuading lawyers to make those changes will be much more difficult if senior and respected lawyers are not leading the effort, and being seen doing so. What matters most is what they do, not what they say.

Project Team Should Include Lawyers, Library and Technical Staff

The project team should include lawyer representatives, as they can provide valuable insight into how the system will actually be used. In addition to the technical staff, the Library should also be represented. After all, their focus is assisting lawyers in finding practice-related information. The project team leader should be the head of knowledge management, if there is one. In any event, the team leader should be a member of the staff with good project management skills.

In addition to the project working team, there should be a 3-person steering committee comprised of senior staff from the Library and Technology departments, as well as a partner. The partner can assist in finding lawyers to be members of the project team and to participate in the pilot.

Recognize Knowledge Strategy Systems Require a Culture of Sharing Information

A firm's culture is often a reflection of its partners values. If the partners view knowledge as power, it will be difficult to implement knowledge strategy systems. Similarly, if partners are compensated purely on the revenues they bring in, they will have less incentive to share know-how than in a firm where partners share clients and have a culture of consultation. Understanding the firm's culture can help establish realistic expectations for the knowledge strategy project.

Start with a Pilot Project

Start with a pilot project, experimenting to see what works and what doesn't. Consider next expanding to a single practice group. In addition to providing helpful input on the design and use of the system, good word-of-mouth from the beta practice group can persuade others to try the system after it is rolled out firm-wide.

Use Lawyer Down-Time

During periods when work for a particular practice group, or even the firm as a whole, is temporarily slow, lawyers may be more available to assist as project team members or pilot participants. It should be recognized, though, that when work picks up, these lawyers may quickly become unavailable.

Prioritize by Value of the Know-How

Put more time and money into projects to manage internal know-how having the greatest value to the firm. Each firm has its own specialized knowledge that differentiates it from other firms. The firm's efforts should concentrate on this knowledge. Systems for retrieving or gaining generic knowledge can usually be purchased from outside vendors.

System Design

Decide Specific Goals for the Project

In designing the system, establish specific goals. For a knowledge-capture project, catalog the kinds of questions the system should answer. For example,

• Have we given this advice before?
• Do we have a good internal example of this type of agreement?
• Who's the firm's expert on this question?
• What have we charged on matters similar to this one?

The pilot project should be tested against these questions.

Decide the Form in Which Documentable Knowledge Should be Captured

For documentable (explicit) knowledge, decide the form in which it should be captured:

• in codified (structured) form,
• in free-form, or
• in a combination of the two.

Whether the knowledge should be captured in codified form depends on whether the subject matter of the information is sufficiently predictable (thereby making it possible to create a subject matter index, also known as a taxonomy), the ease or difficulty of assigning the information to a subject matter category and the preferred way in which users will wish to retrieve the information.

Consider How to Capture the Knowledge

Consider whether existing workflow throws off the desired information. If not, consider how workflow procedures can be changed to achieve that result. Lawyers should never be asked to take an action that solely benefits work product retrieval or other knowledge strategy efforts.

Recognize that Knowledge Sharing Operates Like a Marketplace

Knowledge sharing operates like a marketplace, with suppliers of knowledge and consumers of knowledge. Suppliers expect something in return. By far the strongest incentive to a knowledge supplier is an immediate benefit for providing the knowledge, such as a new use to which they can put the information in their own practice. Weaker incentives include a deferred benefit, such as recognition in future performance reviews or a reputational benefit as an expert within the firm. Another weaker incentive would be avoidance of a burden, such as embarrassment when names of recalcitrant contributors are circulated within the firm.

Extract Every Bit of Metadata from Existing Workflow

Workflow-generated metadata is more valuable (accurate and reliable) than software-generated information. It is also more valuable than information required to be contributed but having no purpose other than knowledge sharing.

For example, software exists that seeks to generate document type metadata for word processed and possibly other documents in a document management system. Where documents are created by word processor templates or macros, more accurate results could be achieved by applying custom software to pass the document type from the template or macro to the document profile. Document type information furnished by users, and that has no significance except to the document search system, is probably the least accurate.

Similarly, the "author" in a document profile typically is merely the most junior lawyer who worked on the document. If the approval process for finalizing the document were conducted through an on-line workflow system, the name of the approving lawyers could also be captured and recorded as metadata. At a minimum, the name of the partner-in-charge of the matter could be recorded as metadata through a client/matter look-up.

For work product retrieval, as much metadata as possible should be included about context, such as industry or other parameters about the transaction or case. Industry data could be captured through client name look-up in a third-party database. Other aspects of the matter could be captured from the firm's matters and experience database, discussed in the accompanying white paper entitled "Knowledge Strategy Project Ideas".

Minimize the Lawyer Bottleneck

Don't wait for lawyers to nominate documents or otherwise furnish information for a know-how sharing system. A better approach would be to implement an entirely new procedure, with its own business purpose, that could generate the needed information. For example, after-matter review meetings could be instituted, principally for the purpose of lessons-learned mentoring of associates. During those meetings, documents could be identified that may be considered useful exemplars for inclusion in the work product retrieval system. A paralegal at the meeting could handle follow-up.

Recognize Differences in Litigation vs. Transactional Applications

The implementation of a know-how sharing system should recognize the potentially different practice needs of litigators and transactional lawyers. For example, in a matter dashboard application, a calendar for the case would probably be an important element for a litigation lawyer. Given the more fluid and unpredictable schedules of transactions, this feature would probably not be useful to transactional lawyers.

Don't Underestimate the Value of Lawyers' Talking

In the effort to create a "system", don't underestimate the value of lawyers' talking to each other as a means to share know-how. Fostering a medium for work-related conversations, such as cross-practice affinity group meetings, could be a "system". For example, establishing regular meetings of intellectual property litigators and IP business lawyers could result in valuable knowledge sharing. Another example could be establishing electronic chat rooms within the firm on particular subjects.

Consider How to Handle Security/Confidentiality

There is a balance between limiting access to sensitive or confidential information and making that information available for use by others. Developing security rules is a complicated but important task. Senior lawyer practitioners should participate in the design of the rules. Senior management should be asked to sign off.

For example, the more advanced search software can automatically apply the security attributes of a document in the document management system, so that only users authorized to view the document in the DMS can search it. Existing document security attributes in the DMS may not be appropriate, however, for a work product retrieval search system. What if the default in the DMS is "Full Security"? What if the default is "No Security"? Devising appropriate security rules should get its own focus as a project element.

Another example of the need for security focus is the inclusion of e-mail in the DMS search or enterprise search system. Users may not expect that their e-mail will be viewed by users beyond those copied or addressed on the original e-mail. Appropriate security rules will need to be devised to balance users' expectations (which can be changed to some extent through training) and security/confidentiality concerns against the desirability of broad user access.

If the System Can't Find the Answer, Have It Point to the Person Who Does

Some types of questions may be too difficult or expensive to answer through an automated system. In those cases, consider designing a system that identifies the subject matter expert or experts within the firm who could answer the question.

System Use

Create Incentives for Use

If possible, create incentives for contributing to or using the knowledge strategy system. Circulating success stories with user's names can both educate and incentivize others. Contests and prizes may produce some short-term results, but probably do not have lasting effects.

More importantly, try to eliminate disincentives for contribution or use. For example, minimum billable hour requirements with no soft or hard credit for knowledge strategy work operates against knowledge sharing goals.

Conduct a Post-Implementation Evaluation

After the system has been rolled out, re-evaluate whether it is producing the desired results and is being sufficiently used. If not, consider whether the problem is the system's function or user training and awareness. Even successful projects are more likely to show slow and steady growth than immediate adoption.

Recognize that hard metrics demonstrating dollar benefits of the system may not be possible. Nevertheless, usage statistics from all users should be maintained and monitored. Anecdotal reactions should be sought from high profile users (partners).

Allocate Post-Implementation Resources

Resources should be allocated for

• ongoing maintenance,
• updating the system,
• lawyer training, and
• periodic reassessment of the system.

Even a good system needs to evolve with the firm's practice and needs of the users.

Conclusion

Some of the principles described in this white paper are mere common sense. Others may be less intuitive. Getting the right people involved in the planning, design and piloting is probably the most important principle. Those people should include the lawyers for whom the system is being designed. Getting their involvement is not easy, but support from the firm's senior lawyers will make it less difficult.

Possible Knowledge Management Projects

For examples of projects in which the above principles could be applied, see the accompanying white paper entitled "Knowledge Strategy Project Ideas".

Questions?

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