September-October 2004
Education and Career Opportunities
ProjectWikis
Rainer Volz
A while ago I introduced Project Weblogs in
this section, as something that can provide a different kind of communication
channel for projects, especially when used with large or geographically dispersed
project teams. Meanwhile Michael
Schrage coined the term plog for the use of
weblog technology in projects. That's right -- weblog technology, not the
blogger attitude. Schrage thinks that the typical, ego-driven attitude of
most bloggers would be rather disturbing in organisations. Instead he asks
corporate users to find new ways to use the new medium for their own communication
needs.
Now, it would be a little bit early to argue whether these new usage scenarios
were found or not, but maybe these would look like wikis? Wikis were originally
invented to provide means for collaborative (or rather collective?) editing
and publication. The probably most famous example of the genre is the Internet
encyclopedia Wikipedia.
An organisation is a collective, so a wiki might be a suitable form of expression
for it.
To make this really clear: I don't want to take back what I said about weblogs
in teams and want to propose now wikis instead. I think it's more a question
of purpose, intent. If I wanted to emphasize the individuals in my team and
their connections to each other or the outside world, I probably would go
for weblogs, if I'm primarily interested in the collective knowledge, then
I would decide for wikis.
Another useful distinction between wikis and weblogs I read recently was
space versus time. In weblogs all entries are ordered by time, reverse-chronologically.
Readers find the most recent entries on the front page and can scroll into
the past, if interested. Therefore a weblog provides a view of discussions
and thought processes over time.
Wikis are more concerned with partitioning (thought-) space into useful chunks.
A wiki page collects the thoughts and opinions about a certain subject. Users
can add little pieces of content to it or just comment the contributions of
others. It's all in the page. Often pages are version-controlled and so the
history of a topic, it's development, can be reconstructed and understood.
All pages of a wiki taken together form then the collective memory of a organisational
unit, from teams on upwards to larger units. Of course, there are also links,
forming connections between the pages.
Something worth mentioning: In contrast to the Wikipedia there is normally
also authorship in wikis. Some systems and use cases prefer to provide authorship
only through the a document's change history, some allow authorship markers
for paragraphs or other snippets in a page. So it need not be a fully anonymous
collective that edits a project wiki. In most project scenarios visible authorship
is required and useful, otherwise we would probably experience very soon a
lack of motivation and contributions.
Of course, the differences just described are somewhat artificial. Vendors
and users are still experimenting, trying to find out what works best in which
situation. The results of these efforts are often mixed forms. There are weblogs
with categories, providing something similar to a wiki topic page. There are
wikis with chronological entries. There is even a name for these forms --
Blikis.
Back to wikis. The characteristics that made wikis so quickly popular are
remarkably similar to the ones of weblogs. They are easy to deploy and easy
to use, especially for non-technical users without knowledge of the web's
lingua franca, HTML. Let me provide some details about deployment, editing,
and organisation -- in case you just thought about using such a thing in a
project.
Recently I had the chance to work with TWiki
for project-related purposes, so I'll take it as an example. TWiki is a well-known
open-source wiki application, that was used successfully in many corporate
intranets. It is based on scripting language. As a result it is easy to deploy
with standard web servers. In fact that is all you need to run it, a web server
and a standard Perl installation. Due to these modest requirements it is possible
to install and use a wiki even in situations where a project is in its early
start phase or the situation is too volatile to justify larger infrastructure
investments. A second advantage of scripting languages is the much higher
probability to find someone in your team or organisation with enough knowledge
to do required customizations.
Even more attractive for many people is the fact that a wiki, as a server-oriented
application doesn't require much on the client side, just a web browser. The
browser is used to read and to edit the pages. There is, of course, a price
to pay for this simplicity. There is no WYSIWYG editing, like with desktop
applications. Editing a wiki pages means surrounding text with codes to format
it. The syntax is simple, but covers most of the normal office requirements.
In TWiki *Bold* will result in Bold, _Italic_ in Italic.
Lists, tables, and links follow the same simple patterns. It's one of the
simplest ways for people to edit and publish web content without having to
deal with HTML or complex tools. The wiki vocabulary is limited, but easy
to remember. This should keep the training requirements low.
With a standard TWiki installation you get a number of webs. "Webs"
are the mechanisms to partition conversation spaces in TWiki. Two of them
spaces are for system purposes -- documentation and administration. A third
one is the Sandbox, a practice ground that is traditional in wikis. Here new
users can try out what they just learned, they can write test pages, test
new plugins, or apply functions for the first time. Since the Sandbox is located
in it's own web, the practice ground is well separated from the real content.
Very useful, if you have to deal with a lot of inexperienced people.
How many of more webs you create for your project is up to you. Webs can be
managed independently of each other, but it is always possible to link between
pages in different webs. A straightforward approach for a project would therefore
be to create a web for each team and let users then create the necessary cross-connections
by linking to each others documents. The navigation between all these spaces
was solved quite nicely in TWiki, because they are colour-coded. If you follow
the standard, every web inside the TWiki installation has it's own distinctive
colour, and so it's not difficult to recognise where you are currently. Even
if you followed a lot of links.
I hope these few remarks provided a glimpse of the potential of wikis. I emphasised
the low-tech, open-source end of the application spectrum because that is
what most people are searching for at the beginning. If you don't like too
much simplicity there are lots of plugins to install, adding requirements,
but also providing more functionality or convenience. And there are of course
commercial wikis. Enough technological solutions to choose from. But the main
question is still whether a wiki is a suitable expression form for your organisation.
copyright® 2003 Rainer Volz
Follow Rainer Volz's Web-based PM Groupware discussion through his previous PM World Today Viewpoints Columns.
Knowledge Management Principles for Project Managers
At the IPMA World Congress in Budapest Hungary I heard an interesting presentation on knowledge management rules for an IT project manager.
Professor Reich of Simon Fraser University in British Columbia Canada declared that there are knowledge management guidelines for an IT Project Manager to follow...
Dr.
Blaize Reich
1.Perform a Knowledge Audit
2.Maintain the Knowledge Level
3.Build a Knowledge Map
4.Develop Process Awareness
5.Create Team Memory
6.Enable Knowledge Transfer between Phases
7.Enable Knowledge Transfer between Organizations
8.Build New Knowledge through Learning and Experimentation
The full text of Professor Reich's paper will be published in the November-December issue of the PM World Today. For more on this interesting exploration of PM Knowledge management and the project manager you might want to contact Professor Blaize Horner Reich Ph.D. or the Simon Fraser University web site.