Wiki Blog

Tip9: Ask the Wiki.

September 4th, 2010

Prompt people to use the wiki. When someone asks about creating space for a project or revising a document, encourage them to use the wiki.

Relentlessly push the wiki usage

This is the bad news. It doesn’t really matter how well you prepare the wiki launch. You will need to (hopefully you will have some early adopters that will support you) push and push and push to get the wiki to its critical mass. Once everyone more or less accepts that the critical information is in the wiki, at least the more dedicated members of your team will have the good habit of keeping it up to date.

Not everyone will participate

It is always easier not to do what should be done. Many people do their job only for the pay check. They are not interested somebody would actually save time later if only they would update a wiki page from time to time.

Entropy always rises, unless you add energy

If you ever had a thermodynamics course, you may remember 'thermodynamics’ second law. This law states that in a closed system, entropy (which is a degree of chaos) always rises. Unless you add energy from an external source, systems migrate to a state of absolute and total chaos. This energy is what you should add. Each time the system tends to decay, you need to put in effort to put things back on the rails.

There is a nice similarity to many business processes in general and wiki updates in particular. You will need to keep paying attention to the quality, completeness and usability of the wiki.

Can I have my own wiki?

A typical question if you are responsible for one or more wikis in your organization. In larger, more regulated industries I have seen many times that the default question to this question is NO. Or processes and procedures are so complex that people actually don’t bother asking the question.

Most of the time it is a good practice to let a motivated team have their own wiki. A minor requirement is that, when needed, content can be linked in between wikis.

If processes, licenses or any other reason prevents you from creating a separate wiki, it is perfectly normal to make a sort of navigation menu on the wiki’s main page. Each menu option then navigates to a sub-wiki where a team can regulate itself in terms of content and frequency of update. Enter the team’s name, the name or pictures of the team members on the navigation page. It will make clear that a subsection really is their private domain.

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.

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.

Tip3: Populate it and they’ll come.

June 1st, 2010

Put content on the wiki; direct people to it using email.

This tip seems a bit counter-intuitive. I mean, that sentence originates from the "Build it and they will come", which has become somewhat of a sarcastic statement. And that also the way the authors meant it. You need great content, that's for sure, but you need to open people's eye to where that content is.

Email is your friend

We've said on many occasions that whatever get's emailed to more than one person, is a candidate to be put in the wiki. So why use mail as your friend? The big difference of course between mail and wiki pages is the push and the pull mechanism. An email is really pushed in the person's inbox whereas the wiki page needs to be navigated to. Because people like short and clear emails, concentrate the gist of what you want the recipient to do with it (understand, take action, remember,..) in the email body, but the background is pointed to by an wiki url.

Topics you can offload from an email to your wiki are: attachments, process descriptions, specifications, and so on. Things you would need to remember or that you want the team to remember.

Your cunning plan

You could of course make the wiki so content rich and so well structured that people can simply not ignore it. Once all the collective team knowledge is in a wiki and that wiki is well structured and easy search-able, you will find that no decision can be taken without consulting some of its pages. The cunning plan is to make the wiki the sole place where up to date information can be found. Archive folders that contain useless and outdated stuff, publish updates of once used files and network locations on wiki pages only. Soon you will see no one can ignore the wiki.

The baseball field in the picture above comes from "Field of Dreams", a 1989 American drama sports film. In this film, Ray Kinsella (Kevin Costner) is a novice farmer who lives in rural Iowa with his wife, Annie (Amy Madigan), and their young daughter Karin (Gaby Hoffmann). While walking through his cornfield, Ray hears a voice whisper, "If you build it, he will come" (often misquoted as "If you build it, they will come"), and sees a vision of a baseball field.

Tip1: Grassroots approach

April 7th, 2010

Start bottom-up, to build the ownership.

Tip 1 in the article "Top 10 Organizational Wiki Tips (and how to use them)" on http://www.ikiw.org/2008/01/21/top-10-organizational-wiki-tips-and-how-to-use-them/ says "Grassroots is best. Start from the bottom-up so people build a sense of ownership of their wiki contributions."

There are many sides to this tip. Typically wiki usage has come from the tech community in a company. It's the project leader that throws some stuff on a wiki and some software developers begin to add content to it. With some luck (and the right company culture) you may get the unit managers and business people on it. Rarely you will get sales or account managers on it. (Those you typically won't get on any system.) I have recently come across someone who succeeded in introducing it up to the VP level. But he hastened to add it had took the company 6 years before reaching that level of adoption.

You don't need to start in the IT department

With WordonWiki, we can work on multiple targets. Any part of the organization that has some content to be shared like background information, business processes, policies and even modest knowledge bases can benefit from the virtues of a wiki. We can finally break away from the software development background. One of our successful implementations started from a sales support department. This company has a need to share the process information needed to get support the sales department in creating complex proposals. Only later the wiki was also used by the IT department.

One important topic you may not loose sight of, wherever you start from, is the "ownership". People need to feel they 'own' the wiki content. It are their attachments, word documents and other mails that finally can go to the wiki. 

How to increase wiki adoption?

As a teamleader or unit manager, these are some things you can do to get the wiki more easily adapted:

• When you get an email from a team member with an attachment, asking for feedback, send the mail right back suggesting to add it in the wiki so everyone can give feedback.
• When someone comes and ask how something should be done, refer to the wiki. If that particular piece of information is not there, propose to add it to the 'Processes' or 'Knowledge base' section.
• If you got a team meeting and some team member asks a question about some topic that others seem to know from the top of their head, always ask: "Could you have found that in the wiki?". If so, tell the person to search for it next time. If not, ask the person who knew that particular bit of information to put it there.
• Builders that are about to start constructing a house, always take a day or two to 'prepare the site'. Many things need to be set up that will make live so much simpler when the actual work starts. Projects with less tangible results would also be helped by this 'prepare the site' phase. A wiki can be one of the first actions you should take. It can be initially as simple as 1 page stating the project's high level goal and due date. Get people around a table, put on an overhead projector and start editing the wiki with everyone around the table. Build a list of topics you and your team members will need to think of. Quickly turn these links into new pages and start filling in with the details of the first level detailing

Please post replies below if you got other grassroots approaches that have helped you.