views:

632

answers:

11

We have a distributed team working on a mid-sized project; I am currently the only technical person involved. At the beginning of the project we had a discussion on what to use for project documentation and we agreed on a wiki.

We are now a couple of months into this project and still nobody except me has put any actual content into the wiki. As usual, Word documents are being sent around; some are occasionally uploaded, but most are not.

When deploying new software I usually spearhead things by just using the new tool and basically 'eating my own dogfood' but in this case I am not the one who can contribute and I don't really want to sit down and convert other people's Word docs into Wiki format.

How do you educate people about the use of the wiki and how do you get them to use it?

[Edit 1] One of the main problems right now is that almost all of the content that is being produced by now is NOT my content, it is mostly SMEs and project management stuff. While I am willing to spearhead, I really don't want to be the document fairy...

The wiki is currently a MediaWiki, we have another instance of it running for another project and that works OK.

A: 

It's always hard to change other people habits - especially when they argue like 'it works - why should we change it?'. Just speak with them about the advantages of the wiki and always refer to it if someone asks something project related.

It's the same problem like forcing people to document their code.

unexist
A: 

How easy is it for people to add content to the Wiki? If people are familiar with Word, they're going to be less willing to type content directly into a web page.

Does it support publishing directly from Word, like most popular blogging software? Does it support Windows Live Writer?

Could you persuade people to at least publish some content this way, even though they can't really use the same tools to edit it later?

Roger Lipscombe
The wiki is a media wiki, adding content is not really what I would consider hard
Harald Scheirich
+5  A: 

I think you should convert a few of the Word documents and put them up on the wiki. Replace the content of the word documents with: 'Content moved to http://...'.

A wiki will never succeed without content - generating content should be your prority if you want people to start reading and contributing to the wiki.

Maybe you can add other content (not documentation) to the wiki? Every time someone asks you a techinical question, consider to put the answer on the wiki. I do this at work. The benefits for me is that the number and length of interuptions go down.

codeape
+4  A: 

I'd asked a similar question and got some useful answers. They are here.

Vivek Kodira
+5  A: 
  • The Wiki should be dead easy to use (for example Trac is easy. Confluence is not). If it is easy the people will have less reluctance to use it
  • Lead by example - if the Wiki has some good content already people will be motivated to add more. If it is empty people will be reluctant to be the guinea pigs
  • Real-life situation when Wiki was useful for your project will make the acceptance much easier
  • Make the manager remind people about using it all the time. To get in the habit they need two-three months of constant reminders
Ilya Kochetov
could you elaborate on the "easy to use" factor here? http://stackoverflow.com/questions/170352/confluence-experiences
Nickolay
I'm interested in your statement about Confluence. We're thinking about moving from MediaWiki to something more feature-rich, and Confluence has a good reputation. Can you elaborate?
ripper234
See http://boltpeters.com/wikipedia/ for some usability studies about Mediawiki (Wikipedia). I know Confluence has rich-text editing and all that, but both my less tech-savvy friends and I (who am comfortable editing Wikipedia) find it hard to use. I agree Trac is easier to use than Confluence, too.
ShreevatsaR
A: 

Start populating the wiki yourself, then when people ask you questions, tell them to read it in the wiki.

Lev
That is what I would usually do, but most of the work being done is not done by me
Harald Scheirich
+2  A: 

The Wiki Patterns web site (from wiki vendor Atlassian) has some good suggestions for how to get people to contribute content, such as the BarnRaising - a group event to create a body of content in one go.

Peter Hilton
Great resource, thanks
Harald Scheirich
+1  A: 

"At the beginning of the project we had a discussion on what to use for project documentation and we agreed on a wiki."

I think the underlying problem here relates to the definition of the word 'agree'. You may think you agreed that - everyone may have said they agreed that - but clearly they didn't agree, since they aren't doing it.

Presumably you made a compelling argument at the time in favour of Wikis, which was accepted. I think now it's time to make the case against emailing Word documents, since you're asking them to give up a practice which they know works, in favour of one which they're told works better, but haven't seen for themselves.

For instance, you could demonstrate things which are not possible in this project, but are possible in the project with the working Wiki. Such as finding anything. Even with Word docs attached to the Wiki, the result probably isn't searchable, and documents emailed in private among the project team are no kind of documentation at all. You also could demonstrate that writing into a Wiki page is no harder than writing into a Word doc, at least within the requirements of the project, since switching to a new language/format is the kind of thing that can initially scare busy people off any technology.

Steve Jessop
Searching is a very poor use case. I've not seen a very good example of a search engine in a wiki and MediaWiki's search engine for example is awful. I'd much rather use "Find in Files" on a bunch of Word documents in a folder on a shared drive.
finnw
The particular example doesn't matter - the questioner must have specific reasons he thinks a Wiki is better, or he wouldn't have asked. Even on search, he specified that Word documents are "sent around", and you can't search something you weren't CCed on.
Steve Jessop
+1  A: 

Make it fun and interesting, not just a dry documentation schlep.

Face it:you are asking programmers to assist with documentation!

As to how: Look how the documentation-phobic programmers are writing documentation on SO (they are, they just don't realize it because it is fun and interesting). Copy the SO-style; you could also maybe fake the rep-stuff somehow, but add something that brings real recognition for it at the end of the day.

slashmais
Just for clarification I am not asking programmers to do documentation, I am the only programmer on the team, every body else has other specialities
Harald Scheirich
+1  A: 

I agree with others - you'll have to do a lot of work yourself in the beginning; and take a look at wikipatterns. For one I would not be pushing people too hard. They should themselves realize that wiki tool helps - it may take a year easily. Fortunately wikis tend to work better as intranet - in terms of ratio of writers/readers.

On the concrete side - deploy or put together and extension that converts word to wiki if you have lot's of word files. And email to wiki. Aldo take a look at other useful extensions - like one for posting source code - if you haven't done it yet.

Looks like there is a solution for word to wiki conversion. Take a look at the question (on SO) How to import word documents into wiki?

1) Help:WordToWiki page on english wikipedia has a script - would be great if someone had put it together into a real MW extension?

2) Try this - Extension:Word2MediaWikiPlus - supposedly it uploads stuff to wiki directly from MS Word, including images (with extra configuration).

Evgeny
A: 

Some practices adopted from the WikiPatterns site that were successful where I work (I was an appointed change agent for wiki-adoption):

  • Appointing "Wiki Champions", natural early-adopters who realise the value of a wiki and who are explicitly appointed to drive wiki adoption.
  • Scaffolding: Creating an outline document and then directing someone who is the source of a piece of knowledge to edit that page and codify that knowledge.
  • Deprecating/Deleting duplicate sources of knowledge or documentation - ie. remove those HR forms from the Sharepoint portal and instead put a link redirecting to the wiki.
  • Educate people through blog posts on the wiki (Confluence has News pages) and open their eyes to what a huge field knowledge management is.
  • Be patient and consistent - organisational change is rarely fast, but keep at it consistently and eventually people will come round!
Mark Gibaud