There has been a battle at my company over how to store and disseminate knowledge. We (speaking as a member of development) have used the Confluence wiki for many years and were happy with it. But less technical staff such as managers, marketing, and sales really hated it. So there was a shift at the IT management level to move everyone to Sharepoint. Their main argument was that Sharepoint was free due to our MS licensing agreements.
It turns out that it wasn't really free because it required many resources from IT to actually get the system up and running in an organized and useful fashion, and even then, development hated it because managing content using a word processor was heavy weight compared to editing a wiki page. (Using a wiki page is nearly as simple as writing things down into a text file.) The non-development types will disagree with this saying that Sharepoint is easy because it is like a word processor, a tool they are familiar with. But the type of work they do is more akin to publishing results where development uses a wiki for knowledge dissemination and creation, more akin to jotting down notes. If it isn't quick and easy to do, developers will just live without doing it at all and this will create some efficiency losses. For development tools, throughput is king, not tools for making things look pretty.
Sharepoint supporters will also say that there is a wiki in Sharepoint. But its really an abuse of the term. It comes with a rich-text editor which gets in the way of everything that makes using a wiki nearly as easy as creating plain text files. The Sharepoint wiki is a great way to persuade everyone to retreat back to the word-file/upload/download paradigm that is native to Sharepoint.
This creates problem's in development. The best team collaboration pattern is a community of cross-functional team members that change/maintain the team's knowledge sharing system with little effort. (It's like Web2.0 content communities versus Web1.0 web pages.)
IT's push to sharepoint caused some splinter groups in development: one faction moved to Sharepoint, a faction of development stayed with Confluence (though under threat from IT that they would pull the plug), and a new faction organized around media-wiki.
The later two groups formed out of frustration of using Sharepoint.
Recently, I was coaching one of the team's that kept their documentation in Sharepoint. Only one or two people bothered to put add/maintain information in Sharepoint. Many did use the site as readers. This created a culture of very little documentation which was out of date. When I moved some of their documentation to mediawiki, suddenly more people started updating any problems they saw and added more documentation. It was amazing to see how using the right tool enabled this to happen.
I've been working with wikis since 2001 and one thing that holds true is that there is a small learning curve that some members of the team may not cross, unless they are pairing with someone to get them going. I've found one simple exercise that quickly gets people using wikis is to ask them to add their contact information to the team's wiki. (Put it on the backlog if they aren't taking it seriously.) To perform this milk run, they are exposed to a few tools which gets them immediately productive, and with that critical mass knowledge, they know how to find more advanced features or how to use existing pages as pedagogical devices. Learning from existing pages is a property that Sharepoint lacks. Sharepoint relies on the usual hunting through menus and buttons because there isn't any "markup source" that can be used to learn from other people's postings.
Remember that wiki means quick. If a wiki doesn't fit this term, then find one that does. Otherwise, no one will use it and that free Sharepoint tool is going to cost you.
It turns out that it wasn't really free because it required many resources from IT to actually get the system up and running in an organized and useful fashion, and even then, development hated it because managing content using a word processor was heavy weight compared to editing a wiki page. (Using a wiki page is nearly as simple as writing things down into a text file.) The non-development types will disagree with this saying that Sharepoint is easy because it is like a word processor, a tool they are familiar with. But the type of work they do is more akin to publishing results where development uses a wiki for knowledge dissemination and creation, more akin to jotting down notes. If it isn't quick and easy to do, developers will just live without doing it at all and this will create some efficiency losses. For development tools, throughput is king, not tools for making things look pretty.
Sharepoint supporters will also say that there is a wiki in Sharepoint. But its really an abuse of the term. It comes with a rich-text editor which gets in the way of everything that makes using a wiki nearly as easy as creating plain text files. The Sharepoint wiki is a great way to persuade everyone to retreat back to the word-file/upload/download paradigm that is native to Sharepoint.
This creates problem's in development. The best team collaboration pattern is a community of cross-functional team members that change/maintain the team's knowledge sharing system with little effort. (It's like Web2.0 content communities versus Web1.0 web pages.)
IT's push to sharepoint caused some splinter groups in development: one faction moved to Sharepoint, a faction of development stayed with Confluence (though under threat from IT that they would pull the plug), and a new faction organized around media-wiki.
The later two groups formed out of frustration of using Sharepoint.
Recently, I was coaching one of the team's that kept their documentation in Sharepoint. Only one or two people bothered to put add/maintain information in Sharepoint. Many did use the site as readers. This created a culture of very little documentation which was out of date. When I moved some of their documentation to mediawiki, suddenly more people started updating any problems they saw and added more documentation. It was amazing to see how using the right tool enabled this to happen.
I've been working with wikis since 2001 and one thing that holds true is that there is a small learning curve that some members of the team may not cross, unless they are pairing with someone to get them going. I've found one simple exercise that quickly gets people using wikis is to ask them to add their contact information to the team's wiki. (Put it on the backlog if they aren't taking it seriously.) To perform this milk run, they are exposed to a few tools which gets them immediately productive, and with that critical mass knowledge, they know how to find more advanced features or how to use existing pages as pedagogical devices. Learning from existing pages is a property that Sharepoint lacks. Sharepoint relies on the usual hunting through menus and buttons because there isn't any "markup source" that can be used to learn from other people's postings.
Remember that wiki means quick. If a wiki doesn't fit this term, then find one that does. Otherwise, no one will use it and that free Sharepoint tool is going to cost you.
