A Process for Knowledge Acquisition and Management

Jeffrey D. Kenyon
Member Technical Staff
U S WEST Information Technologies, Inc.
1801 California Street, Suite 1640
Denver, CO 80202


The knowledge acquisition and management process describes the transition from a knowledge "concept" to a formalized knowledge asset. This process involves an initiator, a knowledge steward, and the implementor. The knowledge itself is described using a standard vocabulary of knowledge types; instances of these types can be combined and reused in a variety of ways. The process also identifies some potential quantifiable process and quality metrics. It concludes with a number of suggestions for steps for integration of the knowledge acquisition and management process into development efforts.


The knowledge acquisition and management process is intended to provide a straightforward means of seeing that knowledge is developed, represented, and maintained appropriately to meet a project's strategic goals. It replaces what is usually an ad hoc process with one that is coordinated with the strategic goals of the organization. With the advent of new tools to better represent and use knowledge resources, and the expansion of responsibilities for employees, it is important for organizations to take a more systematic approach to representing knowledge in order to better leverage it.

The knowledge acquisition and management process is intended as one possible approach. It emphasizes personal responsibility for and ownership of knowledge resources by the individuals who will use those resources (Kim & Mauborgne, 1997). It includes a variety of opportunities to quantitatively monitor the success of the process, and to pinpoint areas for improvement.

The process is intended to be implemented as part of an application development effort, with specific individual responsibilities to be determined. It is critical that these individuals be members of the client organization who will remain in their roles after the development effort concludes.


There are three roles currently identified in this process. Multiple individuals may act in each role; conversely, one individual may act in multiple roles. The roles are:

The Process Definition describes these roles and their interactions in more detail.


This process describes the transition from a knowledge "concept" (basically anything that an interested party believes to be useful to the organization as a whole) to a formalized knowledge asset.

Process Input

The input to the process is any knowledge concept. Using the rather vague term concept is deliberate; the goal is to be as inclusive as possible, permitting the specification of any knowledge that may be useful to the organization. The most common forms for knowledge in most organizations are in documentation (printed or on-line), computer code, and in the minds of employees.

Some examples of knowledge concepts are:

The knowledge concept should be a specific example of some type of knowledge (e.g., "We should be ignoring the MVS message XYZ on machine ABC; it's cluttering up our information display, and we can't do anything about it"), rather than general suggestions with no specific examples (e.g., "can we do something about eliminating unnecessary errors, alarms, and messages").

In the initial stages of development, it is anticipated that there will be no firm criteria for rejecting knowledge concepts; if the concept is inadequately specified, it will be up to the knowledge steward to work with the initiator to develop their concept into something that can be implemented.

As the process matures, and tools to automate process flow are developed to support the process, more formal criteria for judging knowledge concepts emerge.

Process Tasks

The process flowchart in Figure 1 defines and documents the proposed process. The chart also captures the relationships between the roles defined above (initiator, steward, implementor) and specific tasks.

Figure 1. Process Flowchart

The specific tasks identified in the process flowchart are described below.

Generate Specification. The process is initiated by the creation of a specification that describes the knowledge concept to be represented. The information to be included in the specification is dependent upon the types of information that make up the knowledge concept (e.g., the data required to fully specify an alarm may be considerably different from the data required in describing the basic procedure to determine whether an IP is "pingable").

The specification may be generated by the initiator (most likely working in a reactive mode to a problem they've experienced) or by a knowledge steward working proactively to identify new knowledge for the system.

Submit Specification to Steward. After the concept is defined in sufficient detail in the preliminary specification, it is then handed off to the knowledge steward. If the concept was initiated by the knowledge steward, this step is omitted.

Should the process be supported by a trouble ticketing system, or another system automating process flow, this step in the process would be the forwarding of the ticket to the steward, or the act of specification generation itself.

Validate Request. The criteria for whether a knowledge concept should be further developed include:

This judgment should be made within a set number of days.

Complete Specification. The knowledge steward is responsible for adding sufficient detail to the concept so that it can be handed off for implementation. The specification must illustrate how the new knowledge is to be integrated into the existing knowledge structures, or alternatively show how the existing structures are to be modified or replaced.

As part of completing the specification, information should be gathered to objectively assess the value of the knowledge. Potential data points for this task include:

For each of the above data items, points should be assigned (e.g., if the problem addressed results in a system coming down to 0-20% of normal functionality, assign 100 points; if the problem results only in a slowdown to 81-99% of normal functionality, assign 0 points). As a result, each knowledge concept will have its own unique score.

Scoring has a dual purpose:

  1. It drives the prioritization for implementation. Direct assignment of a priority (e.g., critical) is explicit, but is often subjective; the reasoning behind that assignment is often obscure, and what may be critical to one person may not be critical to another. Use of the scoring approach provides a more objective and adjustable means of determining priority.
  2. It provide an objective means of judging contributions to the knowledge base (see Indicators and Measurements, below).

Alternatively, any prioritization scheme already in use may be substituted. For example, an automated analysis of an event log may identify and rank a number of problems, which would then be introduced into the knowledge acquisition process.

Submit Specification to Implementation. Once the steward has the knowledge concept described in sufficient detail, the specification is then handed off for implementation.

Should the process be supported by a trouble ticketing system, or another system-automating process flow, this step in the process would simply be the forwarding of the ticket to the implementor, or the completion of specification itself.

Validate Specification. The implementor, if unable to generate an implementation plan from the specification, may choose to reject the specification, returning the specification to the steward and requesting elaboration on specific points.

The rate of rejection should be monitored closely. A high rate may indicate routinely inadequate specifications, in which case process adjustments may be necessary.

Generate Implementation Plan. The implementor, using the specification, creates a plan for representing the knowledge in one or more of the technologies available.

The plan is placed in a location accessible to both the initiator and the knowledge steward, for review. Should the process be supported by a trouble ticketing system, or another system automating process flow, this step in the process would be the completion of the implementation plan (and automatic availability for review).

Implement Plan. The implementor, using the plan and any subsequent feedback from the initiator or the knowledge steward, represents the knowledge according to the plan.

Test Implementation. Following implementation, but prior to release, the implementor ensures that the implementation of the knowledge conforms to the plan.

Release Implementation. The implementor makes the knowledge available to the community.

Evaluate Outcome. The knowledge steward ensures that the implemented knowledge conforms to the specification. A rating on this success is captured.

The initiator ensures that the implemented knowledge satisfies the need in the real world.

If the initiator is not satisfied with the outcome, they are obligated to identify specific problems and work with the knowledge steward and/or the implementor to resolve those problems. It should be noted that only the initiator may end the process.

If the initiator is satisfied with the outcome, a rating on the success is captured, and the process ends.

Process Output

The output of the process is the delivery of a formalized knowledge asset that meets the needs of the individual who originally instigated its creation, as well as the organization's needs. The characteristics of the deliverable include:

Because of the ownership or "customer" role of the initiator, the process is not complete until the initiator evaluates the deliverable and provides a rating on the quality of the deliverable. The initiator should provide the following feedback:

If the deliverable fails to successfully address the need, the initiator must provide feedback to the steward (and if necessary, to the implementor) on specific deficiencies, and appropriate changes should result. These occasions where the process receives a "failing grade" should be viewed as learning opportunities and evaluated during regular process reviews.


Indicators and measures provide actual data on whether critical client requirements are being met by the process. In this case, the clients of the process are the "consumers" of the organization's knowledge, and the management responsible for meeting their organization's strategic goals.

In establishing indicators and measurements, the following assumptions are made :

Process Indicators

Process indicators, or measures, are taken at critical points within the process and serve as early warning signs that something is wrong (e.g., randomly testing machine parts leaving a work cell to ensure that all parts are within established tolerances). Process indicators are a means of quality assurance because corrective action can be taken before delivering the output to the client.

Potential process indicators for the knowledge acquisition process include:

Quality Indicators

Quality Indicators or measures are usually taken at the end of the process when defects require rework (e.g., Mean Time to Failure, Mean Time to Repair). Quality Indicators provide feedback on the overall success of the process in meeting the client needs.

Potential quality indicators for the knowledge acquisition process include:

The MTTR may also be used to illustrate that the same level of service is being provided with reduced headcount, or with less skilled employees.

Using Process and Quality Indicators

In reality, it is easy for a process to exist on paper, and for alternate, informal processes to spring up. To ensure that this does not happen, it is imperative to:

Process and quality indicators are critical elements in both of these efforts.

Evolving the Process. The knowledge acquisition process will require, at a minimum, frequent minor adjustments during the first year of use, as experience is gained in using the available tools and technologies. The process indicators are used as pointers to where adjustments are necessary. A major rework of the process may also become necessary at some point, if the quality indicators plateau below the desired levels. Ongoing project planning should take knowledge acquisition process reviews and adjustments into account.

Aligning the Process. People generally act out of self-interest. If there are no perceived benefit or consequence to using a process, the process will be ignored. If there is no perceived benefit, and only negative consequences (i.e., users will be punished for failure to use the process), the process will be utilized at the lowest level possible.

In the process definition above, the initiator is viewed as the owner of their own knowledge, and has been given the final approval over whether the formal implementation of that knowledge meets the real-world need. This is intended to make it clear to them that there is a benefit in using the process to get their knowledge into the system. Hopefully, the initiators will see this as an improvement on the current process, in which ideas are "tossed over the wall" to other groups, sometimes never to be seen again.

Illustrating benefit is, by itself, not sufficient to guarantee compliance. Consequently, it is recommended that the process be directly linked to positive (and negative) consequences. This should be done by linking the process to an existing employee evaluation process or program.

Specifically, designated individuals (initiators and knowledge stewards) should be held responsible for generating a specific amount of knowledge during a given time frame. Rather than demanding a certain number of knowledge concepts, it may be more meaningful to assign an expected number of "points" (from the scoring mechanism described above), so that there is a built-in bias towards high-impact knowledge concepts, and away from "junk" knowledge (knowledge submitted to the system for no reason other than to satisfy a bureaucratic requirement).

After the process has matured, and expectations of what a knowledge concept specification includes becomes clearer, it may also be beneficial to factor the rejection rate for an initiator's knowledge concepts into the evaluation process as well.

Knowledge stewards should additionally be held accountable for the amount of time it takes them to complete a knowledge specification for submittal to implementation. Again, an emphasis on points will bias the process towards high-impact knowledge. Another factor to consider for knowledge stewards is the rate of rejection by implementors of completed knowledge specifications.

Implementors should be judged based on the amount of knowledge implemented, tested, and released. Additionally, the ratings given to the implementation by knowledge stewards and initiators should be taken into account.


An ontology is a formal specification of the vocabulary to be used in specifying knowledge (Gruber, 1991). It may be thought of as a network of objects, each of which has attributes or properties unique to that object (and potentially sharable with specializations of that object, i.e., a child object shares or inherits many of the attributes and relations of the parent object), and named relations to other objects.

The purpose of the ontology is to provide a uniform, text-based intermediate representation of the knowledge types specific to a development effort, that is understandable by either humans or machines. The intermediate representation provides a means of describing knowledge, at any level of granularity, without expert knowledge of the specific technologies that will be used to implement that knowledge. This representation is useful on a number of levels.

Use of the ontology as an intermediate knowledge representation form also allows the underlying technologies to be upgraded or replaced, as needed.

The ontology should expand on any work already done to standardize the terminology used in a given domain, to include objects of all types relevant to the project.

The anticipated evolution of the ontology is that it will begin with the identification of certain simple terms (e.g., domain concepts) and their arrangement within a network or hierarchy. As experience is gained in representing the knowledge, complex terms will emerge that act as a means of functionally grouping a number of simple objects together (e.g., a problem/resolution might consist of one or more events, the associated underlying failures, and one or more procedures).

One metaphor for this is LEGO building bricks; a fixed set of objects is defined, each with its own properties, and ways in which it can be connected to other objects. Users may choose to instantiate objects, assemble them in a precisely pre-defined manner (similar to buying a LEGO model, and assembling it as defined in the instructions), elaborate on a pre-defined model, or assemble them in some novel but useful fashion. Ideally, all of these approaches are supported (although computerized support for some of these ideas may not be available immediately).

A software-based tool supporting the ontology should be able to do a number of different things:

In addition, it is expected that any software developed would actively support the knowledge acquisition and management process, and be easily modified in response to changes or refinements in the process.


This document describes one possible approach to the knowledge acquisition and management process. It has been proposed as a means of addressing the specific knowledge needs of a U S WEST project to better manage hardware and software event management for an internal help desk. The process is currently undergoing testing to evaluate its utility and identify weaknesses. To fully integrate this process into a project will require further work.

Process Implementation and Validation. If the process described here is viewed as a preferable approach to the knowledge acquisition and management process, the next step is to implement the process. Implementation would require:

The knowledge acquisition process can be implemented through the use of paper forms and careful record-keeping, but many of its benefits can only be realized through the software-based tools to facilitate the creation and maintenance of the knowledge generated by the process. A rapid development effort of a tool with a suitable front end (e.g., a WWW browser for a heterogenous client hardware base) is a possible approach; if rapid development is not possible (i.e., tools and developers capable of quickly modifying the interface are not available), development should occur after the process has had at least a few months to stabilize. Development of software to support the process described herein is a future objective, along with refinement of the process itself.


Genesereth, M.R. & Fikes, R. E. (1992). Knowledge Interchange Format 3.0 Reference Manual (Stanford Logic Group Technical Report Logic-92-1). Palo Alto, CA: Stanford University.

Gruber, T. (1991). The Role of Common Ontology in Achieving Sharable, Reusable Knowledge Bases. In Allen, J.A., Fikes, R., and Sandewall F. (Eds.), Principles of Knowledge Representation and Reasoning: Proceedings of the Second International Conference. San Mateo, CA: Morgan Kaufmann.

Kim, W.C. & Mauborgne, R. (1997). Fair Process: Managing in the Knowledge Economy. Harvard Business Review, July-August 1997: 65-75.