Comments on: Implementing a Department Wiki? A Writer Shares Some Dos and Don’ts (Guest Post)

By: Timothy

Timothy — Tue, 21 Jul 2009 23:53:09 +0000

In my department, we started out with Mediawiki and eventually switched over to Confluence, which has been great. I noticed that you assumed from the beginning that a wiki needs to be a community effort. In my dept, we controlled privileges and gave only certain people write access from the beginning. Our wiki is used our dept’s documentation database. In Confluence you can assign admins to each wiki space. In our setup, I’m the one guy who posts to my group’s wiki space. The original goal was uniformity of style and organization, and it’s worked well for us. With everything coming through one person (me) the wiki stays consistent. It was interesting to read your experience from a different approach.

By: Rushi

Rushi — Sat, 04 Jul 2009 06:42:06 +0000

I agree to Ali,the development is not a game of kids for it there are lots of factors responsible from shear hard work to the consistency in the business process & the most important thing is the patience for the development !

By: SharePoint Links for 2009-07-03 | MarkSimon.de

SharePoint Links for 2009-07-03 | MarkSimon.de — Fri, 03 Jul 2009 12:36:37 +0000

[...] Implementing a SharePoint Department Wiki? A Writer Shares Some Dos and Don’ts [...]

By: Simon North

Simon North — Wed, 01 Jul 2009 16:46:20 +0000

I introduced a wiki here at Quintiq 4 years ago using dokuwiki (I had a lot of rapidly changing C++ code documentation that made using a wiki that required a database impracticable).

To overcome the content problem, I converted all the existing documentation into wiki format and then started evangelizing. It was a slow and painful process getting a wide buy-in; some business units were quicker than others, but I guess the turning point was getting the customer support department to create ‘how to’ and error resolution topics, which they then took to with some enthusiasm.

We now have nearly 5,000 pages and 360 registered users, with the page count increasing at the rate of about 10 pages per day. It has been so successful that we clone some of the content to an external mirror (support.quintiq.com). It has almost completely replaced our extranet and most of our intranet and, touch wood, continues to go from strength to strength.

Yes, there are various pitfalls along the way, but with a some effort you can make it work … and if you do the results are astonishing.

The latest development was to nursemaid a project team through creating their own documentation in the wiki, which I then converted into a Robohelp context-sensitive online help application.

In the long(er) term, I am now working towards embedding wiki creation into our software so that documentation can be created by the development teams in parallel with the software development.

By: Tommy Curnyn

Tommy Curnyn — Wed, 01 Jul 2009 15:54:05 +0000

Just on the training side of things…
A nice feature in OpenOffice Writer is its export to Meidawiki feature. If training a bunch of your lazy co-workers on how to use Mediawiki tags sounds like a chore, tell them to install Writer; once they’ve written their article, select File > Export and choose the MediaWiki (.txt) option. Then you just paste your tagged text into the Wiki. Sweet!

By: Fabio Cevasco

Fabio Cevasco — Tue, 30 Jun 2009 20:53:34 +0000

I setup a wiki for the documentation department I work for about a year or so ago, and we’re still using it.

Some people started using it right away, either because they already knew how to use it (we went for MediaWiki in the end, also for a faster and less painful deployment) or because they immediately liked the idea.

Others were more cautious, but that’s because they are normally a bit suspicious or simply not used to try out new technologies, but they wrote a few pages.

In one year we didn’t produce hundreds of high-quality articles, but we definitely learned to use the wiki as a internal knowledge repository, which proved to be useful, in particular for problem solving: if someone came out with a solution for a common problem, I’d simply tell him to write it on the wiki to make sure others could easily find it (and they eventually did, in time of need).

By: Mark Cronin Ritter

Mark Cronin Ritter — Tue, 30 Jun 2009 16:31:38 +0000

I think you make some excellent points about how to encourage information sharing.
I tried creating a wiki and a blog on SharePoint. The team I work with was more receptive to the blog format. It was easier for them to post and the Categories function helped them keep on subject. It’s also easier to search. As the admin for the site, I like it because I can keep track of the blog posts and easily edit, add graphics, and hyperlinks. The Comments feature allows team members to develop an idea similar to a wiki.

By: John

John — Tue, 30 Jun 2009 16:30:11 +0000

Great lessons learned!
I fell into the very same scenario at my company. SharePoint was just rolled out and I was enthusiastic about it’s wiki possibilities. You could say I was in the second group of Mark Shead’s characterisation. However, I did see the need for improving how my department colleagues across the globe share up-to-date information on product performance in our customer’s applications. So, in that sense, the wiki solution was perfect for building a knowledge base where all colleagues could share product performance and solutions resulting in all of us contributing and learning at the same time. I submitted the first wiki. To this day it is the only wiki.

One thing I learned was that my colleagues did not want to be put on the spot. They did not feel comfortable writing a wiki only for someone to critize it for it’s lack of technical depth or its inaccuracies. A wiki being changed was perceived as such.

As well as that, most colleagues preferred to continue the practice of writing a traditional weekly report. Writing a wiki was, in their minds, another form of a weekly. In other words duplication of work.

A word about the weekly. It is probably the most ineffective communications tool in existence. The practise is for each person to complete a standard template stating progress, problems, action status, etc for a given work week. This is then sent as an e-mail attachment to the manager. Never to be seen again.