On 24/11/06, Frederik Dohr <FDG001(a)gmx.net> wrote: The aim of a corporate wiki is, instead of "oh, Bob did that for two years, but he left last week ... I wonder how he did it", to be able to say "Bob did that for two years, he left how-to notes on the wiki." How is your office culture? If you have a secretive office culture - where people guard knowledge through fear - a wiki won't fix that. Where I work has a *lot* of internal wikis. Mostly they work per group. I write up something on any process, procedure or in-house application I have to use a lot, as notes to *myself* and others. You know how a lot of people start a new job by getting a notebook and writing everything in it? The wiki should be used for that. It's EVERYONE'S COLLECTIVE NOTEPAD. The actual wiki software hardly matters. MediaWiki is very easy to use and install, but a bit heavyweight for a small team; it also doesn't even try to do access control. My work has various installations of MoinMoin, TWiki, MediaWiki, UseMod, Trac ... my group uses MoinMoin because it uses flat files rather than a database, and it's only used by ten people, so MediaWiki was a bit fat for the job. If there isn't a wiki on how to use corporate wikis, you should start one ;-D - d.

Frederik Dohr schrieb: Well, that is a bit off track. Why should people spent their time on an experiment? Rather: Use the wiki to solve a problem. If the employees share the problem, they have an interest in solving it. Advertise that use with presentations. For us, it is the documentation on our IT-System (SAP) with huge amounts of self devoloped coding. It is rather difficult to retrieve information on projects more than two years ago. no. you need to give some direction in the beginning. And you need to have some kind of means to force people to use the wiki. We startet with a simple template for the interfaces to and from our system. It is fairly easy to fill a template article, so the knowledge on how to use the wiki can be very little. Small steps in the beginning. Then a couple people should find it interesting or rewarding to work in a wiki. Encourage that and help them solve their problems. people talk with another. Teach the use and the possibilities of the wiki. Half a day is short but a good starter. Make the wiki mandatory for certain types of information. Mostly it is limited time of the workers, to put down that information. have someone help them with it. regards, Gunter

Thanks a lot for all your responses and links for further reading! The problem is that in my current position (technically I'm just an intern), I have no way of handing out motivators of any kind - let alone making use mandatory. Even getting everyone to just enter their name and position (to make them take a look at the wiki) is quite a challenge... And the project leader wouldn't be willing to take any such steps before he sees that the wiki is actually working - kind of a catch-22... I will get the chance to make a (very brief) presentation though. Obviously I'll have to make a good case for the wiki there (not one of my best qualities) in order to get people to at least consider using it. So as of now, I'm hoping for a "cascade effect" where a few eager colleagues will pick it up, and then others might follow. (I will of course be present to answer whatever questions might arise.) As for a WYSIWYG interface, I'd agree that while this might erase the intial obstacle, its (current?) limitations would likely lead to frustration further down the line. I'd consider WYSIWYG if advanced users could just turn it off, but it seems that all available solutions/extensions change the way contents are saved, creating an either/or situation. (This might also lead to complications when trying to export contents from the wiki for use in some other medium!?) Thanks again for you kind and truly helpful contributions! -- Frederik

Our group got wikis started in a big way at Intuit, Inc. Wikis need a champion - and that's YOU right now. Start using the wiki for yourself, documenting projects, figuring out article structure and classification. I would highly recommend getting a decent search system on it - if you have a Google appliance in-house, use it with one of the extensions documented on the Meta site. When people ask you for info, point them to the wiki article about it. If there's no wiki article about it, create one and THEN point them to it. I've actually had people email me about something on the wiki that needs to change. I just email them back and tell them "It's a wiki, dude. Change it yourself." That's a tough one. Different wikis require different structure. Best to create a basic structure that you think works and let it evolve. Don't be afraid to create multiple "landing" pages and see which one works best. We have to constantly warn people about choosing between one of Intuit's three "self-help" management, documentation and collaboration tools: Wikis, Blogs and QuickBase. Here's a blurb from our documentation about choosing a collaboration platform (from a wiki, of course): -------------------------------------------------------------- A wiki is a great tool, but it isn't the right tool in every situation. Do you need/want active collaboration? * If the answer is no, a wiki isn't for you. Are you creating information that will be used/referred to over a span of time? * If the answer is no, you probably don't need a wiki. Are you primarily looking to have a conversation or build an information repository? * Wikis have a built-in mechanism to support comments (the Talk page) but if you place more importance on the conversation than on the documents sparking the conversation, a wiki probably isn't the best fit for your project. Consider a forum or a blog. Is process central to your project? * Wikis are generally process-less, which means they aren't the best way to manage a process. If you care about tracking status and issuing alerts, consider Quickbase. -------------------------------------------------------------- - MHart

I'm afraid I'll have to agree there; I've realized that my initial hope that the wiki will be self-organizing from the start was actually quite naive.... I agree, Wikipedia really isn't the best example in terms of structure. I realized this when trying to pull some content from their help section for use in our wiki - that almost made my head spin! (Disclaimer: I love Wikipedia and couldn't live without it.) So I'll definitely take a good look at cookbookwiki.com - thanks for the tip! -- Frederik