H. Knowledge Centers

Introduction

As Communities of Practice coalesce, they reach a point where they begin to focus not just on building connections, but also on documenting aspects of their domain of expertise so that new members, emerging leaders, and the organization at large can leverage this knowledge. A Knowledge Center is a virtual repository for collecting, organizing, and disseminating these knowledge assets. The most common technology features that support a Community of Practice's Knowledge Center are:

• A home page to assert their existence and describe their domain and activities.
• A conversation space for on-line discussions of a variety of topics.
• A facility for floating questions to the community or a subset of the community.
• A directory of membership with some information about their areas of expertise in the domain.
• A directory or links to external experts and relevant content sources inside and outside the enterprise.
• A shared workspace for synchronous and asynchronous electronic collaboration, discussion, or meeting.
• A document repository for their knowledge base, including items such as lessons learned, best practices, lists of useful web sites and relevant articles, recommended reading lists.
• A search engine good enough for them to retrieve things they need from their knowledge base.
• Community management tools, mostly for the coordinator but also for the community at large, including the ability to know who is participating actively, which documents are downloaded, how much activity there is, etc.
• The ability to spawn sub-communities, subgroups, and project teams.

While the purpose of building a Knowledge Center is to provide a framework and repository for a community's knowledge assets, Knowledge Centers provide assets for more than just the community. Many communities use Knowledge Centers to showcase and disseminate their expertise to the enterprise as a whole.

Outcomes

• Identification of the types of assets that the community wants to develop and/or collect
• Inventory and folder structure for these knowledge assets
• Taxonomy structure for asset organization
• Process for collecting assets of various types
• Process for reviewing or "certifying" assets
• Process for maintaining or archiving assets

Methods and Resources

Knowledge is of two kinds. We know a subject ourselves,
or we know where we can find information about it.
Samuel Johnsons

The Knowledge Centric Organization Toolkit is a resource guide for developing Knowledge Centers in organizations, and the KCO process encourages development of communities to facilitate the flow of ideas across organizations and the enterprise. The organization's Knowledge Center may or may not constitute the community Knowledge Center. It should, however, always serve as an additional source for communities and, ultimately, a repository for community knowledge artifacts, those ideas that have facilitated the creation of knowledge in one individual and have the potential for facilitating the creation of knowledge in others. The Naval Sea Systems Command (NAVSEA) Community of Practice Practitioner's Guide includes detailed recommendations for establishing a community knowledge base, which have been combined with recommendations from the KCO Toolkit and CoP Best Practices into the list below.

• Inventory existing assets: Inventory offers community members the opportunity to identify all media associated with established business processes. With the help of a facilitator or community leader, convene a session of community members and conduct a brainstorming session on media that are either inputs to or outputs from the community's business processes.
  
  

  Once the list has been developed, assign each member the responsibility of reviewing the baseline list and adding media not captured during the community session. Compile the baseline list along with the individual input from community members. This will become the baseline inventory for the community. As you identify each asset, begin to capture the key meta-data listed above.
  
  

• Build or identify a taxonomy: This is the organization and classification of information: Although the CoP knowledge base will not be the organization's main information repository, the knowledge base may grow until it contains such a large number of documents and other knowledge artifacts that users have difficulty finding what they are looking for in a timely manner. This is the same challenge faced on an organization's Intranet, although at a smaller scale in the CoP. In order to provide users with an intuitive and effective means to interact with the knowledge base, both for obtaining and contributing information and knowledge, the information should be organized with classification systems designed with a conceptual framework. This framework will allow the information to be consistently classified to make it easier for users to know where to look for various types of documents and records, and may be the same framework used for the organization's main repositories or a customized version for the CoP depending on the organization's policies and standards. The conceptual basis of the framework is the ontology which can be created for many applications and have many coordinating themes, such as business topics, technology functions, and tactical military capabilities. This conceptual framework is translated into a hierarchy of descriptive categories that forms the taxonomic schema used to control the classification process. Taxonomies can be standardized, like the Library of Congress or Defense Technical Information Center (DTIC) taxonomies. Alternately, a customized version can be developed especially for the needs of the enterprise. However, extensive experience with enterprise taxonomies in DoD, National Intelligence services, corporate intranets, and the Internet has shown that enterprise organization architectures must define which user perspective, or perspectives, will form the framework for the classification scheme. For example, an enterprise classification scheme can use a taxonomy based on the core business areas, the organization hierarchy, primary product lines, or even an external schema such as the new North American Industry Classification System, which was jointly developed by the USA, Canada, and Mexico to facilitate North American commerce.
  
  

  When creating taxonomy, remember that this is a hierarchal structure that needs to respond to the information needs of individuals within the community. Therefore, it is useful to use an organizational schema that is already known and used by members of the community in other systems. For example, in an acquisition office considerable effort and thought has gone into developing a work breakdown structure that is specifically applicable to the work of the office. This structure can provide a beginning point for developing a taxonomy for an acquisition office.
  
  

  Finally, since there are taxonomies at all levels of the organization and enterprise, it is essential that taxonomies developed for communities either align with or relate to organization-level taxonomies. Alignment means that the taxonomies match vertically, while relating means that the community taxonomy can be mapped to the organizational taxonomy, which in turn must be aligned with or mapped to the enterprise taxonomy. Organizing data and information using aligned or related taxonomies facilitates the flow of community intellectual resources into organizational Knowledge Centers and enables future enterprise interoperability.
  
  

• Identify or design processes for collecting, reviewing, and maintaining assets: Use flow modeling, mapping, or any other technique that works for you to document processes that will ensure that new assets make it into the Knowledge Center, and that both existing and new assets are "certified" by the community. One successful architectural model for a Knowledge Center is to have multiple types of content with different "certification" levels. For example, discussion threads are typically unedited. If you use content in a discussion thread, you will be doing so "at your own risk" since it's possible that either the information is not accurate (any more) or may not be relevant in all cases. White papers or other lessons learned may have a status of "peer reviewed," the community may require new papers to be reviewed by a minimum of two community members before they are posted. Best practice documents might be those documents that are certified by the community as being the definitive technique or framework approved by the community.
  
  

  Assets of all types are valuable to community members. Sometimes a practice may just be too new to become a best practice but there are still others who could benefit from learning the approach. Whether some or all content must be peer reviewed or certified before it appears in the Knowledge Center is a community (and organizational) decision, but it is important to make these decisions as the Knowledge Center is being designed since it could be prohibitively expensive to have to retrofit Knowledge Center content "after the fact."

  One of the quickest ways to kill a Knowledge Center is to permit the content to become inaccurate or out-of-date. Even before there is a lot of content for the Knowledge Center, it's important to have a process for how you will ensure that the content in the Knowledge Center is maintained. For example, the system could automatically generate a message and link to each content author (or contributor) every 6 months to have her check the accuracy and relevancy of the content. As content grows, there should also be a process for removing or eliminating old content. Rather than arbitrarily removing content based on a document-aging scenario, it makes the most sense to integrate the archival strategy with the content maintenance strategy. For example, give authors the option of deleting the content if it is no longer relevant.
  
  

• Determine rules for each asset (content management strategy): Asset rules provide members with guidelines for moving data in and out of the knowledge base. An example of an asset rule is using a compound document instead of a folder to collect and present periodic volume releases of a newsletter. Establishing asset rules provides a consistent means for interacting with the knowledgebase. Asset rules should be reviewed periodically to ensure applicability and effectiveness.
  
  

  Sets of asset rules exist for each business process supported. Regardless of the size, rules must be put in place to avoid difference in practitioner usage. Asset rules will most commonly be identified with a business process. However, in some cases, specific documents may have an asset rule associated to it specifically. For example, a particular community maintains a community calendar within its groupware application. The document format of the calendar is a Microsoft Word file. To provide guidance to the community on the use of this document, the following asset rules have been created:
  
  

  • Calendar only maintained by assigned owner
  • Community members who need to add a date to the calendar will use the groupware's document Check-in / Check-out function
  • The community will maintain three months of its calendar. One month of past events and two months of future events
  • All community members will create a change notification on the community calendar thus allowing them to receive email notification upon calendar update
  
  

  It is important to capture and record the following for each asset, independent of the technology tool used to catalogue the Knowledge Center assets:
  
  

  • Date created
  • Author and/or Contact Person
  • Contributor
  • Access rights (community only, enterprise, people outside the enterprise)
  • Date last updated, reviewed, or modified
  • Expiration date
  • Review cycle (date or frequency with which document should be sent to owner for update or review)
  • Classification (based on taxonomy)
  • Review status (certified best practice, peer reviewed, not reviewed, etc.)
  
  

  Asset rules must also be established to facilitate the movement of core information into the organization's Knowledge Center, making sure that the context of the information is transferred with the information.
  
  

• Determine strategy for finding knowledge assets: A critical key to success of any Knowledge Center is the ability to find content; all Knowledge Centers need a search facility. Ideally, Knowledge Centers should include a single search engine that enables users to find content in all the various repositories with a single query. The ability to "subscribe" to content categories, searches, or documents, and receive notification of updates in e-mail, helps to make a Knowledge Center "sticky." This also ensures that community members will have a convenient vehicle for keeping the community relevant to their "day job."
  
  

• Provide Training: Training ensures that all community members possess the necessary skill to function within the collaborative work environment. Community leaders should not assume that its members understand and can operate within the Knowledge Center without training and support. Training can be accomplished within the community by identifying a training lead for the community. Typically, this person will possess an above average aptitude for Information Technology and has a good grasp of the business processes.

Creating Knowledge

At its heart, building a Knowledge Center involves converting tacit knowledge to commonly held, "explicit" community knowledge. Tacit knowledge is that personal "know-how" that is difficult to articulate because it is derived from individual experience and beliefs. Includes what the organization knows and what it knows how to do but cannot express and codify. In contrast, explicit knowledge is formal, documented knowledge identifiable in such items as policy documents or operations and procedures manuals. What is really conveyed are knowledge artifacts, a term used above to define information that has facilitated the creation of knowledge in an individual, and has the potential for creating knowledge in others.

Knowledge shared in a community Knowledge Center can take many forms, including documents, white papers, lessons learned, best practices, etc. The following techniques and tools offer alternative ways to create content for the Knowledge Center:

• Ad-hoc sessions
• Roadmap to generating new knowledge (problem solving and brainstorming)
• Learning history
• Interviews
• Action learning
• Learning from others
• Relationship building
• Systems thinking

Technology

In March 2001, Etienne Wenger, a thought leader in CoPs, produced an analysis of technologies for the Federal CIO Council geared towards Communities of Practice.¹ The Wenger results underscore the need for a culture and technology base that grows and adapts to the needs of an organization. The report suggests that there is no one single technology platform that provides complete support for a community Knowledge Center. Rather, Wenger suggests that the ideal system will arise from combinations and convergence in the market as it matures.²

Figure 1, from the Wenger report, provides a graphic representation of some of the current market of community-oriented technology products.³


Knowledge Centers do not necessarily require specialized technology. It is far more important to develop simple processes for collecting content and keeping it current in what ever format it is stored than it is to spend a disproportional amount of time selecting the "perfect" technology environment. The motivation to use technology to support Knowledge Centers and communities is to make it easier to connect people to people and people with information. If the technology environment is overly complex, disconnected from the users typical desktop or day-to-day work environment, it doesn't matter how "perfect" it is-it won't be used. Technology for Knowledge Centers must be:

• Easy to learn and use because communities of practice are usually not people's main job,
• Easily integrated with the other software that members of the community are using for their regular work so that participation in the community requires as few extra steps as possible
• Not too expensive. If it requires a lot of up front investment, potentially useful communities will not be able to take advantage of the platform and will not be able to build their Knowledge Center.⁴

Examples

There are several examples of Knowledge Centers (or emerging Knowledge Centers) across the Department of the Navy. The following describes two of these examples.

• The Special Needs Families (SNF) CoI supports families who have a family member with special educational, emotional or medical needs. Because medical and educational benefits and support services vary widely from state to state, the leaders of this community are creating databases that describe what families can expect as they move to their next duty stations. Families are able to access the SNF CoP using the LIFELines online KM Tools, which include Hosted Chat Rooms, Moderated Discussion Groups, Ask An Expert Policy Forum, Electronic Surveys and Polls, eBlast Newsletter, Online Directories, FAQs, On Call Assistance 1-800 Database, LIFELinks (favorite hotlinks to online resources) and SNF Community of Interest page within LIFELines.
  
  

• The Engineering Network (E-NET), sponsored by Naval Facilities Engineering Command, plans to capture as much tacit and explicit knowledge as possible to help NAVFAC build a reusable knowledge base. This knowledge base is expected to support the nurture and growth of their engineering community using multiple knowledge centers. Each Community of Practice has as its center a focused group of practitioners and experts organized around functional areas (i.e., Pavements, Electrical, Mechanical, Interior Design, and so forth). Each Community of Practice has developed a Community of Interest for non-members of the CoP who have a passing interest in that subject. The CoP has limited access (password access) to the CoP discussion space. The CoI provides access to experts, news, relevant readings and other pertinent information. The CoI will offer customer access to experts, help and other needs. Knowledge sharing and learning occurs where the CoPs and CoIs overlap, building a potentially robust and dynamic corporate knowledge base.

  
  As the CoPs and CoIs evolve, NAVFAC expects to create a more robust list of documents, threads, FAQs and any other information the Community needs to build its knowledge base. This body of activity comprises their Knowledge Center plan. The rollout (access and notification) to their customer base is planned for August 2001. They are currently using Cold Fusion and Allaire Forums to support their E-NET Intranet activities. This allows for the listing and access to experts, threaded e-mail, CoP and CoI pages, as well as relevant document access. As the NMCI, portal activities, and other technologies evolve, NAVFAC expects to move forward with enhanced technology support for their Knowledge Centers.
  
  

---

Footnotes:
¹Wenger, Etienne. (2001). Supporting Communities of Practice: A Survey of Community-oriented Technologies. Published as "shareware" and available at www.km.gov under "Group Documents", then "Documents and Resources." Also available in this guide under the Resource section.
²Ibid, P. 5.
³Ibid. P. 9
⁴Ibid.

Attachments (Hide)

File Size(Kb) User Date Version CoPs.gif 36 Karl Hebenstreit Mar 21, 2008 9:14 PM 1 header_knowledge.gif 6 Karl Hebenstreit Mar 21, 2008 5:17 PM 1