Tip7: Trust me. Don’t excessively manage it.
July 21st, 2010
A wiki doesn’t have complex approval mechanisms for a reason. Trust people to write quality content and they will.
A wiki is not a publishing engine
In a previous live, we have worked for some years in the publishing industry. That industry has its particular processes for content creation, indexing, storage, retrieval, review and finally publication build. Quite easy to understand when you know that the final product need to be pushed out to professional printers that, after some final processing, print it in high quantities. The professional publishing industry now publishes much of its content online. The result is that its cycle time can be drastically reduced. Yet most of the processes still apply.
Approaching a wiki with a publishing background is a definite no-no. The wiki built in mechanics concentrate on a superfast edit/publish cycle. One key feature in this is the knowledge that all changes are visible, all author actions are exposed and, if desired, all mistakes can easily be reversed. This is what is called a game changer. In other entries in this blog, we have made the case that the wiki contains many of the publishing functionality in one neat, easy to manage and understand package. Content creation, linking, indexing, versioning, review and publishing are not only all there, but they also are contained in one neat package.
So yes, the wiki content is also 'content', pushing the 'save' button can be considered as publishing and the more advanced wikis even add auto indexing, keyword management and some sort of 'table of content' creation. One big difference is that the wiki is a two way process. The reader can adapt, augment, correct, complete the content that is proposed.
So how to 'manage' a wiki?
Pushing content out there and get the wiki 'the' reference source is the task you want to accomplish. Put all of your organization's knowledge on a place where you know you can find it if nobody can be reached. So focus on getting the critical mass in there and get your team into the habit of updating and maintaining the wiki regularly.
But after some time, 6 to 12 months in most cases, you will see that the self organizing capabilities of a wiki may need some gentle push or discrete clean up and restructuring. We have called it 'Spring cleaning' before suggesting that its frequency will be rather low. Typical actions you may take are listed below:
- Put the wiki cleaning and restructuring as a separate topic on the team quarterly meeting agenda.
- Use new projects or special events as the reason to add new content to the wiki and archive old pages
- Suggest searching wikis for specific problem situations that the team encounters. If your team finds it, see if it is still up to date. If not found, grab the opportunity to add a new wiki section.
- Don't hesitate to archive complete subsections of the your wiki. Add a section called 'old' or 'obsolete version' and move stuff over there. It will not be lost and you have made room for new and fresh content.
Know it will never be perfect, never finished
This is probably more a problem for some people than for others. Some people take hours or days before they are happy with the result of their content creation. Just because everyone can see what they wrote, they get stuck in polishing and re-polishing the content. They much rather not publish anything. One trick that can help is to just open the relevant pages during some meeting or some face to face talk, and just start editing. Taking notes on the fly. After the meeting you forward url's to the pages to the relevant people asking them to complete it.
Tip6: Don’t rush it.
July 14th, 2010
People will need time to get used to the wiki, and once they do it will grow significantly.
Every team has its own speed
There is no hard rule here. Some teams can get up to speed in a matter of weeks, other organizations will take months to grow into the habit of a successful wiki. I have seen often that people new to the wiki start overly enthusiastic and add tremendous amount of content in the wiki. Only to find themselves out of breath a few weeks later.
Save one page and you got a wiki
Some project and team leaders consider a wiki project as a real 'publishing' job. Including review cycles, editorial guidelines and restrictions on who can say what. Wrong. Very wrong. As soon as one introductory paragraph is written and saved, consider your wiki as 'published'. Now it is up to the team to amend it, correct it and provide structure.
Of course some preliminary ideas on what will go in the wiki will help. Hints to complete topics can simply be part of the pages. This is what makes wikis different from 'documents'. No need to annotate, comment or add revision marks. Simply add [to be reviewed] or [tbd] flags next to topics. Everyone reading the topic will be hinted gently to provide the content if they can. If it is wrong or incomplete, the next person visiting the page can still correct it.
Some people have asked us if it is better to foresee a lot of empty pages, laying out the structure of the wiki in great detail. While that may seem like a good idea at first, it generally isn't. If you create 15 to 20 pages like that, chances are high 5 or more of them will never get filled. They give the wiki a sort of 'Abandoned city' view. By the time the team gets to fill them, the situation will have changed and new insights will have come. You will then end up with a lot of dead end and orphaned pages that remind you how foolish you have been to think that one day some one would fill it.
Better is to write a short paragraph of what you think should be added or detailed. Hints like
- Somebody fill this is...
- To be completed. Pete/John/?
- Should this get more stuff added?
- Somebody amend this paragraph, I am not sure it is technically correct.
- And my favorite: Some inspiration here please! My kingdom for some insights!
Create a sense of urgency
The first of the 'Change Management Principles' of J. Kotter is to create a sense of urgency. We need to act now, or else... While you can hardly extrapolate it to any team deliverable, setting up a wiki certainly falls into the category of 'getting things moving'. Copy&paste some text on the main page, add diagrams and reference to other documents and walk your team through it as though it was a PowerPoint. Make clear it is 'Work in progress', and you rely on the team to provide extra material.
Now what?
You managed to get the ball rolling, the team has relatively well picked up tasks and some material is provided. Now prepare for the long and hard work. The novelty will wear of quickly and if you don't get some critical amount of content in there, the thing will die even before it got off the ground. Relentlessly push the use of the wiki forward, use all other tips on this blog to push it. Prepare for a typical 6 to 8 weeks of getting to some kind of momentum. Good signs the wiki is picking up are:
- Content subsections start to appear without you knowing it
- People start complaining when the wiki is down for 1/2 day or more
- The team is actually pushing you to enter information in the wiki
- A core team of heavy contributors is established
- Your mail volume goes down, especially in terms of attachments
If you have tips on how to take it slowly, let us know...
Tip5: Go to the source. Put some content exclusively on the wiki so people get used to it as the source of information.
July 7th, 2010
Your way to make the wiki be the true source of content is to make it indispensable.
Part of the cunning plan
We've written about this before. In most business situations, there is a lot of collective knowledge that cannot be remembered by most people. So all these typical topics are good candidates to be put in the wiki. We give a list of possible 'unique reference opportunities' below:
Reference information on people
- Your team members are the first candidates to be put in the wiki. I have used every occasion I got to create personal pages for each team member. I provide some basic information about name, location and so on. Then send the person the link to his page with a request to complete it.
- Basic lists like contact lists containing phone numbers, msn and skype id, email links, home phone numbers and so on are a pretty easy target. If you see it is used by many people, put a link to it on the home page.
- Great content like the team's barbecue pictures, or references to news articles or other publications seem like bringing little value to the wiki, but it surely attracts many visitors. If you are not using an easy to use way (read 'drag&drop') to insert pictures in pages like WordonWiki offers, you may find yourself doing quite some editing. As a tip, don't drop all links in the page, but make sure the pictures are visible when opening the page. To get people in the habit of editing pages, insert some funny captions along with each picture and invite others to do the same for the other pictures.
Reference information on the work/project
The names of the people from the customer site are often very interesting to be put in a dedicated wiki page. Don't be afraid to also add a line of explanation what each name really means. Indicate their role in the customer organization and explain for what they are supposed to be contacted or not.
Any reference or url to the selection of company processes or methodology elements that are applicable to the team can be referenced in a separate page. Don't hesitate to add explanatory text of how the team should judge the application of these standards. You can explain why some guidelines are absolutely essential and how some others are only of secondary importance. Your team will appreciate you put how and what to apply in writing. As a word of caution: beware of regulations that can exist in your company or industry.
Major milestones, important deliveries, budget or timing constraints should be explained in clear and simple terms. Don't use overly formal language. Rather write things down as you would explain it in a team meeting.
Dedicated topic pages
Each team and project will find itself from time to time facing a big challenge. Some nasty bug that is bothering them, some crash exercise to remedy a crash situation, some change project or alike. These topics often merit a set of dedicated pages. Something like a wiki in the wiki. You will find these pages get consulted and updated a lot during the crash exercise and are much less visited later. However that is not a problem. You will thank the effort you have put in as a team the day a similar problem reappears. You can quickly tap in to the knowledge that you built up six months before.
Don't bury pages to deep
One experience we would like to share is to take care not to bury pages to deep in the hierarchy. Although today's search algorithms should help you find back quickly the information, this only helps if you know there is some content that you can search for. If you are just browsing page content, make them rather rich in terms of number of links to other pages. It helps to limit as much as possible the depth of the navigation tree (Maybe max 4 or 5 levels deep in a wiki of a few hundreds of pages). One way we have used successfully is to have the links to all the dedicated topic pages directly accessible from the home page. Instead of creating an link to an index page, put all the dedicated topics one after the other on the home page. Even if you got 10 or 15 of those, it will only take 2 or 3 lines and people are immediately confronted with new links that are added.