Page 203 -

186 Chapter 6

particularly in reuse. Another aspect of the explicit knowledge problem is the fallacy
that documentation (explicit knowledge) equals understanding. We seek understand-
ing in order to successfully reuse a component. However, the larger and more complex
the component, the harder it is to gain the required understanding from documenta-
tion alone. Understanding, in this context at least, is a combination of documentation
and conversation — conversation about the component and the context in which that
component operates. No writer of documentation can anticipate all the questions a
component user may have. Even if this were possible, the resulting documentation
would be so extensive and cumbersome that potential users would simply develop
their own component rather than wade through the documentation.
Knowledge management systems that focus on gathering, recording, and accessing
reams of knowledge, at the expense of person-to-person interactions, have proven to
be expensive and less than satisfactory. Organizations that fail to understand tacit
knowledge will repeat many of the mistakes made with methodologies such as com-
puter assisted software engineering (CASE). A common assumption in the past was
that all relevant knowledge could be bundled up in nice, neat, easily accessible pack-
ages of “ best practices ” that practitioners could then “ repeat. ”
When we attack reuse as a KM problem, we begin to ask new questions, or at least
look for different avenues for fi nding solutions to the problem. How do we go about
fi nding the component we need? How do we gain confi dence that the component
does what we want it to do, and does not do strange things that we do not want?
What is the distance (organizationally or geographically) between the component
developer and users? Are there other people who have used this component that we
could talk to and learn from? Do we have access to the author of this component?
Have others found this component to be effective? How should we go about testing
this component? How easily will this component integrate into our environment?
Dixon (2000) outlines factors that affect knowledge transfer: characteristics of the
receiver (skills, shared language, technical knowledge), the nature of the task (routine,
nonroutine), and the type of knowledge being transferred (a continuum from explicit
to tacit). The author then identifi es fi ve categories of knowledge transfer that she has
observed, from near transfer ( “ transferring knowledge from a source team to a receiv-
ing team that is doing a similar task in a similar context but in a different location ” )
to serial transfer ( “ the source team and the receiving team are one and the same ” ).
Dixon then describes techniques that work well for each of these fi ve types of
transfer.
It is not the objective of this chapter to describe the practices of knowledge transfer
in detail, but rather to point out that merely coding a component and scratching out