Information Technology Reference
In-Depth Information
edge should try to create maps to make it easy to
identify and connect with experts; this is easier to
create, but there is less potential for reuse. Wikis
can be adapted to either strategy, or to a combina-
tion. The collaborative editing capabilities allow
experts to contribute more explicit knowledge
to the system, while the wiki version history can
help to identify experts in particular topics so that
they can be contacted directly.
In the author's experiences, most wiki KM
systems begin by capturing explicit knowledge,
usually by uploading or copying and pasting
content that already exists within the organiza-
tion. Common mapping techniques include
departmental directories, user home pages that
describe responsibilities and interests, and links
to external resources. However, it is common for
mapping to gradually emerge in the KM system,
particularly when the system uses social network-
ing features, such as comments, discussion forums,
frequently asked questions, and ways to rate the
quality of information in the system. People can
then identify experts from the frequency and reli-
ability of their contributions to related topics in
the wiki. Researchers are investigating ways to
assess the reliability of wiki content and authors
(e.g. Priedhorsky Chen, Lam, Panciera, Terveen,
& Riedl, 2007; Viégas, Wattenberg, & Dave,
2004; Viégas, Wattenberg, & McKeon, 2007); in
the near future, wikis should incorporate tools for
automatic assessment.
and can speak to each other directly. The people
involved in the pilot should be open to new ap-
proaches, focused enough to be successful, but
diverse enough to be representative of the roles
and attitudes across the organization.
Pilot projects worked well at SalesCom and
EnginCom - in both cases, wikis were initially
developed by small groups who could experi-
ment freely and adjust as needed. In contrast,
ResourceOrg started by designing high-level
structures and supporting tools, some of which
were never used.
Simple but Representative Structures
Albert Einstein is quoted as saying “Make ev-
erything as simple as possible, but not simpler.”
This is certainly true of wikis for collaboration
and KM. Keep the initial structure simple so that
users can understand it and so that it can adapt as
the KM system evolves. At the same time, make
the structure complete enough that users can see
how the larger system will work (Blake, 2006).
Remember that “all models are wrong, but some
are useful” (Box & Draper, 1987, p. 424); provide
structure to help people be productive, rather
than trying to address all possible problems in
a comprehensive structure that isn't relevant to
immediate needs. Also, match parts of the wiki
structure to the organizational structure. Conway
(1968) famously observed that system designs
(particularly in software) mirror the structures
of the organizations that produce them. Ensure
that each team, department, or division using the
system has a home page, with links to parent,
child, and sibling units. Fortunately, in a wiki it is
easy to maintain multiple navigation structures, so
knowledge can also be accessed in other ways.
SalesCom developed templates for the most
common pages; periodic reviews of new pages will
help to identify opportunities for more templates.
Initially, SalesCom imposed very little structure,
although this may present challenges as the system
grows. Conversely, EnginCom chose to create a
Pilot Projects
Appropriate pilot projects are important to get
collaboration and KM started in safe, supported
environments, with supporting structures and
examples that will help the system expand in the
future (Mader, 2008, p. 63). Initially, pilots should
be small enough to be manageable; it's better to
do one thing well than many things poorly. At the
same time, pilots need to be big enough to illus-
trate the system's value; it might be unnecessary
if all of the participants work in the same office
Search WWH ::
Custom Search