Best lame excuse of the day not to use the wiki
November 16th, 2010
A developer in the project team where I do consulting had been struggling with some new code. The code was perfect, but the problem was a lack of documentation. Nobody knew how to configure the thing. So precious hours were lost just before the scrum demo later that day.
One would hope the developer's reaction would be to document the found settings in the wiki or installation manual so that the same hours would not be lost again. Instead this guy wrote an email detailing every frustrated step he had to take and mailed it to the support email box of the company.
The developer knew the support email box was automatically converted in todo-items for the system administrator. The system administrator was the most likely person next in line to run into the problem.
When asked about the justification of these bizarre actions, the developer responded: "Well, I keep this email in my sent items folder so the system administrator cannot say I never told him...."
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.
Tip2: Throw out the rule book!
April 28th, 2010
Don’t start with a lot of structure and rules. Make a wiki available, then see how people use it, and grow accordingly. Follow the lead of the people using it – that’s at the heart of how social software works!
This tip goes to the heart of what the web2.0 movement is all about. Everybody is contributing. In this way, the result is better than what you would ever get when you tried to enforce it to your team or department.
It is not really the absence of rules that constitutes to the success of a wiki, but the freedom that people feel that they can take part in it when and how they want.
Why does 'absence' of too many rules gets teams on average to a better result? What motivates people to take the time to enter a new wiki page or to amend an existing one. In general because they feel that is something they ought to do.
Revisions, the feature you need but will rarely use
The single most important feature that explains why you don't need too many rules is the wiki's revisions system. Everything that was ever there, good or bad, is remembered. And is there for everyone to see. I have seen only on rare occasions that somebody had to revert to a previous version because somebody messed it up. People just need to understand that that feature is there. This understanding will keep them from spamming the wiki or getting engaged in some foolish escalating correction upon correction game.
The question of motivation comes back later, when we will try to understand what it is that makes people wanna come back to the wiki to make it better.
Page templates should help, not enforce
A word of caution about page templates. These templates are available when pages of a certain type are created. These should not be viewed as "fill in all the boxes on this form, or else it is invalid". Rather it should help new page authors structure the information on the page so that some kind of uniformity is reached. Rather use templates to assist on what kind of content is typically provided on a page of that nature.
I don't know where we are going, but we are getting there very fast
This is a slight exaggeration of course, but there is some truth in it. You may know where you start with a wiki, but you will need to have an open mind to see where people take the wiki. Don't try to limit the use of your wiki when it goes into a direction you did not anticipate. When the team decides that they need content on a topic, try to understand rather than to stop it.
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.
Confront the brutal facts: Five ways to measure your wiki's success.
February 19th, 2010
When you are introducing a wiki, you want to know how you are doing. Also you may like to confront your team with the actual usage numbers. You can only improve, what you measure.
The research on what other wikis typically use didn't bring a lot of insight. Apart from some helpful statistics on good'ol wikimatrix that simply compares wiki solutions, we didn't find a good set of indicators that tell you something about the health of your wiki. So we sat down with the team, and below you can find what we came up with. We'd love to get comments on what you found useful and what worked for you in the past.
First thing to decide is about the frequency of your measurements. Daily nor weekly make sense according to our experience. Remember, when setting up a wiki, you are in for the long run. Slowly you need to get it in the back of everybody's mind that the wiki needs updating, amending, correcting,... Showing the monthly view to your team is the optimal frequency.
1. Who's who
The (variation of) the height of the graph below shows how your user base is growing. One requirement of course is that you capture who is accessing the wiki. Many wikis do not require registration, some not even for writers. In a business environment, which is anyhow WordonWiki's target, this is less common. Management typically wants to 'control' who has what access.
The various stack segments show how many of our users 'can' read or 'can' write. Note that this only tells something about the segmentation of the user base, not about the actual use. The sample graph below is a typical example for a relatively small wiki, small in terms of users. In line with popular believe, most people should be able to correct something if they want to. So it is not uncommon to have most if not all users with write access.
2. Wiki Activity
Unless you have a very outspoken team, you will most likely see that most people are simply viewers. Only a minority is actually editing pages. Of course, a wiki is primarily used to get information, so growth in absolute numbers of logins is certainly a good thing. If you are brave, you could even divide the total number of logins (filtering out users that log in for a second or third time) by the number of (work) days. This gives you how many times per day, somebody turns to the wiki to get information or add something.
During our brainstorming, some one suggested to break down this number even further: to the team/unit level or even to the individual user. In the end, we're not convinced that this would be helpful to move things forward. However, it would be very confrontational to see who is almost never using the wiki, or who has rarely added something to the wiki. Please send us your idea's on this.
The case of the graph above clearly shows a wiki that is relatively new and a lot of information needs to be added. Even after 4-5 months of operation, a lot of edits still go on. When this is wiki for a more process oriented business, you will see the number of edits drop over time.
3. How recent is your wiki's information?
Next we present how many users did NOT log in for two weeks or more. Also we plot the number of pages that were not updated or read. Both of these lines have of course a correlation with the number of users and pages. For all lines on the graph, less is better.
4. Time for spring cleaning?
The longer you are active, the more junk you accumulate. This is true for all the stuff in your house, and it also applies to your wiki. When the ratio of pages that are not 'in use' becomes to high compared to the total number of pages, you are probably in need of some serious cleaning. Now people hesitate to get rid of old pages. 'We may still need it', is an often used excuse for not cleaning up.
One way to solve this is to create an 'Old' folder and move all outdated pages to that folder. You move stuff out of the way but you can still reach it if you need to.
One anecdote that painfully illustrates this point is our own story. Due to some software programming problem, the page delete option could not be used in one of our early releases. It took more than a month before we noticed this. None of our users had complained. It seems like a feature that nobody really missed!
5. Who is doing all the work?
The last graph shows two dimensions. Firstly, the size of the pie charts show the number of users over time. Secondly, each pie shows the percentage of the users that do 80% of the page updates. With sufficiently number of edits&users, this should ideally reach 80%. In reality that figure is likely to drop to 40% or even lower.
Over to you...
Please comment on this post to post your wishes for meaningful indicators and graphs.