More on Wiki Adoption
Twitter
Facebook
Delicious
Digg
Stumble
Reddit
This text is being republished here from the comments to a previous post.
I am posting it front and center because a couple of people also asked me about wiki adoption today, and I think these might work for them.
——————-
I will admit I used strong language but it was based on some frustration. Let me tell you about our experience with wikis
We use a wiki within our company, but the first people to adopt it
were HR and Marketing  they needed a tool to help them get organized
in specific plans. From their success, Engineering and ITCOMM have
automatically shifted to the tools. I would say our adoption has been
smooth.
The road we took was to first identify areas of inefficiency in our
work, and find tools that explicitly allowed us to gain in those areas
without adding additional overheads and inefficiency. That is a
straightforward approach that most operations consultants would take.
Now the important thing is that this is an implementation of a
continual improvement process  the goal given to everyone is to
improve their ops, and they themselves find a model that works for
them. That is one of the reasons Wikis work for us, because they gave
everyone a bottoms-up approach to modifying the wiki around their
specific workflows.
In the end, they have vested interest in getting together to use the
Wiki. What’s more, all we have had to do is constantly explore new ways
of adjusting work models around wikis with the goal of improving the
functions’ throughput.
So for us, people either “get itâ€Â, or “dont get itâ€Â, and if not, we
just start doing Thought Experiments and workflow efficiency analysis
with them.
For ITCOMM and Engineering, the shift is usually more
straightforward  often because most good engineers are also well
organized in my observation.
OK, so all that background aside, I will also admit that we still
face some snags on our adoption roadmap  there are people who do not
contribute as often, or do not follow the teams’ conventions or
structure.
So I went to wikipatterns quite like you are hoping  to find answers to our adoption challenges.
To be honest, I spent 2 hours on it and all it did was give me a
migrane. Even back in the hayday when I was designing satellite
base-stations I didn’t see anything so technical as those patterns.
So obvious question is  why should I have to resort to drawing out
a map of fairies and trolls or character profiles on a whiteboard
before I can start getting enough clues to understand how to fix
adoption issues?
If I am trying to find a human solution to a human problem, why start with patterns and character profiles to begin with?
I argue that in most of my consulting career I have not yet seen any
technical people that have an influence in the day-to-day workflows of
other functions. The only thing they can perhaps to do is Internal
Marketing of Wikis (i.e. raise awareness).
However, the adoption decision for each department  in fact, each
person  is based on understanding the benefit to me from using it.
So I argue that you should definitely look to your adoption patterns
with a “sales oriented focusâ€Â. Call it post-deployment sales of the
benefits of wikis to internal teams.
I also argue that even technical people will have a hard time
actually adapting the Patterns to their specific situation. Even if
there has been some good work done in identifying “Patterns†of
behaviour, they should only be consumed by academic interests such as
the study of social behaviour in the enterprise. I have my doubts that
these patterns  atleast as they are  can be much useful.
There is no doubt that we need a “best practices for adoption†guide
for wikis, but this is just the wrong approach. As I went there, if
your customers are going to that website as a means of finding
after-sales support, then they might just end up thinking “This company
has no idea what my problems areâ€Â.
I am glad to know that you guys are working on a “marketingâ€Â
version, but all I am arguing is that we need a “human†version first.
Don’t sell me on wikis, just help me understand them in language
that I relate to… You are, after all, the person that introduced me
(the average consumer) to it.
9:47 pm
I like this post. It neither too short nor too long. It makes its point clearly (kindof the opposite of wikipatterns, as far as it seems
. And most importantly, it emphasizes strongly the fact that a wiki is not so much of a piece of software than an elegant solution to coordination, participation and sharing issues.
I need a place I can access to publish and exchange information easily, not an “amazing bottom-up integration coordinated with attachments in a powerful search engine that sends RSS feeds to your mailbox without you having the hassle not to go further for a wiki page”…
2:34 pm
Thanks for the kind comments.
Yes, many software vendors simply forget that technology is a means to enabling improvement in life.
E.g. if all someone needs is a way to support active collaboration and discussions between teams by providing an even, democratic playing field, then even a blog where the entire team can publish works great