Assuming that you already know what the word Wiki stands for and what it round about is but you a) either still ask yourself why you should have one for yourself/ company/ project or b) you introduced a Wiki system but it hasn't been put to much use or c) you wonder if there are certain "best practices", then this article is for you.
It is mostly intended for people that try to evangelize for Wikis within their company/ department/ project but can be read by anyone interested in learning more about Wikis.
Introduction: Why on earth a Wiki?
A Wiki system can have different goals. It generally helps with the 1) transfer of knowledge and encourages 2) knowledge sharing among parties and can dramatically increase the information flow between team-members/ business-units/ companies/ etc.
I have seen Wikis that failed and others that were highly successful.
"As with all knowledge management tools, they live from the participation of all. Without such a tool being used by its intended users, it suffices no one."
This may sound simple but to get people to use a Wiki will be your (if you are the person in spearheading the effort) main responsibility and indeed way to measure your success. You will have failed in your change management attempts - because indeed any attempt to introduce a new knowledge-management tool is such - if people will rarely use the Wiki for its intended purpose, will have found other means (of course only "bad" if the alternative is less effective) to communicate and interact and/ or if your users created little information islands (more on that later on). The latter meaning that they input information into the system but fail to link to other bits and pieces within it, therefore creating data islands that fail to create real knowledge.
A good test for a Wiki system that is used for knowledge transfers/ sharing is to simply put someone with no or only slight understanding of what he is about to see in front of it and get back to him at end of day. If he is in a position to ask intelligent questions you will succeeded in creating something truly useful.
Best Practices:
1. Think in Wiki
A Wiki allows one easy editing, you can focus on the more important aspects of the content (what are about to say) instead of its layout (how it will look like). All Wikis allow basic content structuring such as bulleted/ numbered lists,
Assuming that you already know what the word Wiki stands for and what it round about is but you a) either still ask yourself why you should have one for yourself/ company/ project or b) you introduced a Wiki system but it hasn't been put to much use or c) you wonder if there are certain "best practices", then this article is for you.
It is mostly intended for people that try to evangelize for Wikis within their company/ department/ project but can be read by anyone interested in learning more about Wikis.
Introduction: Why on earth a Wiki?
A Wiki system can have different goals. It generally helps with the 1) transfer of knowledge and encourages 2) knowledge sharing among parties and can dramatically increase the information flow between team-members/ business-units/ companies/ etc.
I have seen Wikis that failed and others that were highly successful.
"As with all knowledge management tools, they live from the participation of all. Without such a tool being used by its intended users, it suffices no one."
This may sound simple but to get people to use a Wiki will be your (if you are the person in spearheading the effort) main responsibility and indeed way to measure your success. You will have failed in your change management attempts - because indeed any attempt to introduce a new knowledge-management tool is such - if people will rarely use the Wiki for its intended purpose, will have found other means (of course only "bad" if the alternative is less effective) to communicate and interact and/ or if your users created little information islands (more on that later on). The latter meaning that they input information into the system but fail to link to other bits and pieces within it, therefore creating data islands that fail to create real knowledge.
A good test for a Wiki system that is used for knowledge transfers/ sharing is to simply put someone with no or only slight understanding of what he is about to see in front of it and get back to him at end of day. If he is in a position to ask intelligent questions you will succeeded in creating something truly useful.
Best Practices:
1. Think in Wiki
A Wiki allows one easy editing, you can focus on the more important aspects of the content (what are about to say) instead of its layout (how it will look like). All Wikis allow basic content structuring such as bulleted/ numbered lists, simple text-formating (bold, italic) and so forth.
Content needs to be created. If it should end up living in the Wiki, then go ahead and create it right there on the spot! Don't be afraid of unfinished, untidy content. It's all about creating a Wiki that lives, breathes and grows.
And yes, it may happen that a colleague will see one of your "unfinished products". Never mind and relax, you are not going to get fired but your boss should promote you to employee of the month for using the knowledge management tools assigned to you in a productive way!
An easy solution is to mark items that are yet to be done as just that: "In progress", "under construction", "just did it", "V0.01", you name it. But beware not to use such labeling excessively as it can lead to an infection of your wiki with half-finished content.
A Wiki can also be used as a sort of sticky-note, it can become your personal to-do list, your schedule. To start and try out is all it takes and be assured that most of the times the seeming chaos will evolve into order.
2. Wiki once a day
The process of creating content should be an integral part of your daily activities. My slogan is "document while talking, talk while documenting".
Personally, I have come to know Wikis as excellent supporting tools to document technical systems. Next time you explain someone a line of code or some sub-system remember to keep a Wiki page open and to type as you speak. When you are done explaining it to him, you will have a working documentation in front of you!
Every time you catch yourself that you are the only one that is "in the know" about a particular area within your company/ project/ etc. this should create an impulse for you to take the wiki-pen into your hands and to start to type.
A question that of course always comes up is: "Why should I make the knowledge I gained available to anyone else?"
Personally I believe that everyone has to find their own answers. I can only say that to be giving pretty much always helps yourself in the end. For me it has meant that through knowledge transfer I was able 1) to always have room and grow into new, even more exciting tasks and 2) to learn a great deal from others in the process.
A nice by-product of sharing knowledge with your co-workers is that you become their mentor; you will gain in status and respect in the eyes of others. Oh, and there's nothing against telling people you shared; just don't brag. :)
3. Link all that is CamEled
= "Links increase the value of the WikiWikiWeb" =
Context - which is important to create and make knowledge lasting - is created through intelligent linking within and across Wikis. They think like we do: in hierarchies and networks. Always be on the lookout for already existing content when creating new pages.
4. Change often and with reason
Content remains a living thing if you keep it up-to-date. As things around us change at an ever-increasing pace this becomes a daunting task, however without updating our Wikis they will dry out and will become an information wasteland.
Especially see if the structure of information is still relevant. Re-group, re-write to reflect the organization around you in the real world.
Once again, integrate wiki-ing into your daily life and you will succeed!
5. General tips for well structured content
* At the top, establish a context: Tell the reader what the page is about.
* Tell important information first, go into details later. Think of the wiki page as newspaper article. Readers are impatient: they start at the top and read down.
* When appropriate, use categories for automatic indexing. See WikiCategories.
* Unless you prefer anonymity, sign and date your comment.