Creating Knowledge Objects

This document represents a historical foundation for an intent is to provide an environment to which they people could refer their description of a real organizational or business situation and obtain approaches for dealing with the situation. The idea was to build what might be considered a large Q&A repository, yet that would be quite an understatement of its potential. While people may be able to very readily describe a situation they are attempting to deal with, the question they ask is rather universal: "How do I deal with this situation?" Asking this question generally doesn't get one much closer to an viable approach for dealing with the situation.

The intent was, based on an organizational situation description, to provide insights regarding what are the meaningful questions to ask, along with the information, knowledge, and wisdom appropriate for answering the questions, along with approaches for dealing with the situation. While our advances in technology continue to create new organizational challenges many organizational challenges have been the same for thousands of years. It's just new people that have to deal with these same situations. The idea was to provide, within an organizational context, and intelligent response to the requirement:

"I need to know what I need to know when I need to know it;
even when I don't know what I need to know."

Admittedly this is quite a tall order. The paper is meant to provide a set of guidelines for employing technology to respond to this requirement. Much of the foundation for what follows was conceptually developed in Knowledge Management: Emerging Perspectives and Principles of a Knowledge Leveraging Community Infrastructure.

The idea was to refer to the contents of the system as objects. Where an object has the following definition:

A knowledge object is a highly structured interrelated set of
data, information, knowledge, and wisdom
concerning some organizational, management or leadership situation,
which provides an viable approach for dealing with the situation.

While this effort never managed to come to fruition much of the conceptual work is still considered valid.

Content was to consist of a large number of knowledge objects, where each object is composed of terms, concepts, and statements related in ways to distinguish one knowledge object from another. These components are defined as:

Knowledge objects fall somewhere on the following continuum based on the extent of the interrelatedness and context independence they exhibit, along with the understanding they provide.

The idea being that as the degree of interrelatedness of the statements increases the object they define becomes more and more context independent. The intent is to create objects which have as high a degree of interrelatedness and context independence as possible, while providing as substantial a foundation for understanding as possible. These objects would then reside somewhere on the continuum from data to wisdom. An object with a high degree of interrelatedness that doesn't provide understanding would be viewed as complicated. An object that provided a high degree of understanding with very little interrelatedness and very context dependent would be mundane.

Feedback on the previous paragraph indicated that an example of complicated and mundane objects might be in order, so here's an attempt:

Complicated
Goal: Why do people do what they do?
Fact: Energy follows the path of least resistance.
 
The above is a complete solution and the Fact is the answer to the question posed in the Goal, yet I'm sure it won't be readily understood by many because it is simply a statement of wisdom, with no foundation.
Mundane
Goal: What is the nature of water?
Fact: Water is wet.
 
The above is also a complete solution, which just happens to tell you something everyone already knows, and as such would probably be considered quite mundane.

Objects then provide the user with information (what?, when?, where?, who?), knowledge (how?, a foundation for viable action), or wisdom (why?, with implications of action) because of it's consistency and lack of ambiguity.

When creating objects there are a single governing consideration: reusability, where reusability is defined in terms of findability and usability.

To achieve a high level of reusability it is essential to consider:

Statement Types

Objects are created using statements. Each statement has one of the following six roles assigned. An object may have multiple statements of each type, and objects need not use all types in its definition. (These roles were adopted from the Primus software implementation).

Type Description


Goal
A goal is a stated objective. A goal describes something the user is trying understand or would like a description of (Information), trying to figure out how to accomplish or deal with (Knowledge), or understand the reasons for or implications of (Wisdom).


Fact
Facts define the context or environment for the Goal, or within which the Symptoms, Changes, and Causes are relevant. Facts essentially represent a constant context which remains unchanged after the fix is applied.


Symptom
Symptoms are used to describe a situation one perceives within the context defined by the Facts. Symptoms define the situation one is attempting to determine how to deal with. Symptoms often, but not always, represent unwanted aspects of the situation and cease to exist when the fix is applied.


Change
Change statements described things which have recently changed within the context and may have been responsible for the causes creating the situation that is being described.


Cause
Cause statements define the underlying foundation, or basis, of the situation the user is experiencing. Cause statements define why the situation is what it is.


Fix
Fix statements provide a definition or description (Information), define the actions one should take to deal with the situation being experienced and accomplish the goal (Knowledge), or define the why or the implications of actions (Wisdom). Applying a fix should result in removal of the symptoms and achievement of the objective. If there is a need to provide supporting information of any length, e.g. beyond a page or more, the Fix should contain a hyperlink to a web page which contains the information.

An attempt to depict the relation between the various roles is provided in the following diagram.

The implications of this diagram are:

An object is defined using one or more occurrences of as many statement types as necessary, and no more. An object should contain only those statements necessary and sufficient to provide a foundation for the information, knowledge or wisdom the object is meant to present to the seeker. The interconnectedness of the statements should form an unambiguous situation description, its context, and a fix which enables the appropriate understanding and viable action.

User Interaction

The following is a description of how the system interacts with the user to determine the relevant objects that should be offered for review. This interaction needs to be taken into account when you are developing the content of the object. Remember you are attempting to develop objects which are both findable AND usable.

The system does not do key word searches to identify relevant objects. A well defined object represents a pattern, and the description the user provides represents a pattern. The system determines the relative similarities between patterns and provides the user with a list of objects which have a high degree of relevance to what the user defined. The best thing to keep in mind as one creates objects is that one is creating patterns, and these patterns are often dynamic, displaying a transition and direction over time.

Statement Form

The following is a list of considerations which should be kept in mind when creating individual statements which compose the pattern of the object.

Much of the utility of the system is based on its ability to reuse statements in multiple objects. If a statement is very short and concise it stands a chance of being part of more than one object. Statement reuse aids the system in making content associations between objects. Statement reuse is part of the key to object findability.

A point of relevance: If there are two objects, one with 5 statements and one with 10 statements, and the user provides 1 statement which is contained in both objects the user's input has a higher degree of relevance to the 5 statement object than to the 10 statement object. The implication is that you should endeavor to create objects as concise as possible. Think about necessary and sufficient, and once you satisfy both, throw the rest away.

Creating Objects

There are actually many approaches to object creation, yet what follows is considered to be the most straight forward approach we've come up with so far. It can also be helpful to interact with the knowledgebase to see what it currently contains that you might connect with as an aid to creating new objects.

Step 1:

Write a description of the situation being experienced. Don't worry too much about being absolutely complete. Just write down the experience that comes to mind as the situation has developed over time. Maybe the best advice is to write the description as a story which unfolds over time.

A very complex project was initially on scheduled and going quite well. A key member of the project was offered another opportunity and left the project. It took us a while to find a replacement. The new person is quite capable and is coming up to speed rather well. The project has been slipping and is now behind schedule. We're beginning to get lots of heat about the fact that we're falling behind schedule.

Step 2:

Rewrite the description as a set of short concise statements each of which represents a complete thought.

Complex project
Project initially on schedule
Project initially going quite well
Key member left the project
New project member found after some time delay
New project member is quite capable
New project member coming up to speed
Project schedule slipping
Project behind scheduled
Organizational pressure because of schedule slip

Step 3:

Determine the roles for the statements and reorder as appropriate when the roles are assigned.

Fact: Complex project
Fact: Project initially on schedule
Fact: Project initially going quite well
Fact: Key member left the project
Fact: New project member found after some time delay
Fact: New project member is quite capable
Fact: New project member coming up to speed
Symptom: Project schedule slipping
Symptom: Project behind scheduled
Symptom: Organizational pressure to get the project back on schedule
Change: Key member left the project

Step 4:

Are there additional statements that could be added to make the object more robust; that is more findable and more usable? Think about what the pattern affects and other things that have an affect on the pattern. Patterns don't exist in isolation and the connections are important.

Fact: Project Management
Fact: Resource Productivity
Fact: Project Scheduling
Cause: People require time to develop understanding

The addition of Fact(s) at this point also forms relevance linkages to other objects with the same Fact(s).

Step 5:

Establish a Title for the object being created. A Title statement should be unique to the pattern described by the object.

Title: Manage project schedule slippage due to resource changes and acclimation time.

Now create a Goal statement for the object which is more reusable.

Goal: Manage project schedule slippage

This situation also implies that there should be additional objects defined in the knowledgebase. These might be:

Goal: Manage resources to reduce the need to replace them.
Goal: Minimize the time needed to replace resources.
Goal: Manage schedule expectations.

Step 6:

Now write the Fix for the object that's been developed.

Fix: With a realization that the new individual will take time to come up to speed there are several options possible.
1. If there are others with the same or similar skills they should take up the slack while the new individual is coming up to speed, and they should aid the person in their acclimation to the project.
2. If there are no others on the project with similar skills the project may need to have the time frames replanned to accommodate the real productivity during the acclimation period.
Fix: The answer to this situation is definitely not adding more resources. Adding additional resources simply detracts from the productivity of those already on the project because the additional resources will also have to be acclimated.

Step 7:

Put all the pieces together for the completed object.

Goal: Manage project schedule slippage due to resource changes and acclimation time
Fact: Project management
Fact: Resource productivity
Fact: Project scheduling
Fact: Complex project
Fact: Project initially on schedule
Fact: Project initially going quite well
Fact: Key member left the project
Fact: New project member found after some time delay
Fact: New project member is quite capable
Fact: New project member coming up to speed
Symptom: Project schedule slipping
Symptom: Project behind scheduled
Symptom: Organizational pressure because of schedule slip
Change: Key member left the project

Cause: Complex projects require new member acclimation time
Fix: With a realization that the new individual will take time to come up to speed there are several options possible.
1. If there are others with the same or similar skills they should take up the slack while the new individual is coming up to speed, and they should aid the person in their acclimation to the project.
2. If there are no others on the project with similar skills the project may need to have the time frames replanned to accommodate the real productivity during the acclimation period.
Fix: The answer to this situation is definitely not adding more resources. Adding additional resources simply detracts from the productivity of those already on the project because the additional resources will also have to be acclimated.

Note that one could break this into two objects with different Symptoms regarding whether there were others on the project with similar skills and abilities. Each object would be coded with the appropriate part of the Fix from above. This is a judgment call on the part of the person developing the object. Often there simply is not just one right answer.

Step 8:

Walk through the review questions and common problems in the next two section to see if you can improve on the object pattern.

Object Review Questions

Once you've developed an object forget that you know the answer. Go back and read the object as though you were the intended audience. If the user in need of assistance described the situation would the answer you provided be a sound basis for action. Objects aren't developed for people who know the answer -- what sense would that make. Objects are developed to provide a basis for action for individuals that need to act. If the object doesn't accomplish this, what is the likelihood that the user will indicate that they found the object of value?

Common Problems

The following seem to be some very common problems associated with the development of objects.

Statements vs Sentences:

While Goal & Fix statements should be complete sentences, Fact, Symptom, Change, and Cause statements should be complete thoughts. They do not need to be complete sentences. The intent is for these statements to be as short & concise as possible and still contain a complete thought. As Fact, Symptom, Change and Cause statements may be presented to the user for relevance clarification out of context they must individually make sense out of context -- thus the requirement for being a complete thought. The reason for wanting them to be as short and concise as possible is to improve the possibility that the statement may be used in more than one knowledge object. The sorter and more concise the statement is the more probable its reuse becomes.

Fact Statements:

Facts are used to define the context in which the rest of the object is considered valid. An object which is appropriate for a new business startup may be quite inappropriate for an advanced stable enterprise. Facts could also be used to define the knowledge domain the solution is related to, such as Business Development, Team Dynamics, etc. Aspects of the situation that were true for the environment before the situation described and after the Fix is applied are probably more appropriate as Cause statements, or as part of the Fix.

Change Statements:

Change statements represent things that have changed in the recent past and are probably reasons the Cause(s) now come(s) into play. Change statements do not represent things that need to change in the future.

Goal/Fix Relationship:

For a specific goal there should be only one fix. If there are multiple possible approaches then there must be something that determines when one fix should be used rather than the other. This would imply a difference in some part of the pattern so two separate objects should be coded, one for each approach. Don't worry about the redundancy. We know we're sacrificing efficiency for effectiveness.

Symptom/Fix Relationship:

For a specific set of symptoms there should only be one fix. If there are multiple possible approaches then there must be something that determines when one fix should be used rather than the other. This would imply a difference in some part of the pattern and two separate objects should be coded, one for each approach.

Cause/Fix Relationship:

For a specific cause, or set of causes, there should only be one fix. If there are multiple possible approaches then there must be something that determines when one fix should be used rather than the other, and this would mean a difference in some part of the pattern, and that two separate objects should be coded for the one Goal.

The concepts developed here are continued in Landscaping Knowledge.

References

Landscaping Knowledge

theWay of Systems * Feedback * Musings
Copyright © 2004 Gene Bellinger