Glostra Wiki
Child pages
  • Advice on Wiki Adoption
Skip to end of metadata
Go to start of metadata

Although Wikis are technically easy to implement, being extremely light-weight and user-friendly, a successful wiki adoption, in whatever environment, requires a lot of planning, engineering, and ultimately: work. As stressed earlier, e.g. in the sections Enterprise 2.0 and Enterprise 2.0 - Implementation, the process of bringing Web 2.0 inside an organization is not simply about technology, but essentially involves a strong people-aspect, and requires a major change in the underlying organizational culture. This also applies to wikis: simply erecting a wiki and hoping that people would start collaborating more is not enough. The change has to be more fundamental in order to make a true difference.
In this section, we'll explore possible ways of enhancing wiki adoption in a corporate environment - and making it stick. As the various potential benefits of wikis have already been largely covered in "Wikis", this section will not concentrate on trying to prove the usefulness of wikis in corporations.

It is also fair to say up-front that this page relies heavily on the ideas presented by Stewart Mader in his blog, "Grow Your Wiki", and on the content in Wikipatterns.com, an extremely inclusive wiki-based site providing information, ideas and instructions for the wiki adoption process. Definately worthwhile exploring both sites carefully.

A good way to start this introduction to wiki adoption might be to actually show a couple of examples of wikis already used in companies, just to make sure your doubts about ''real-life'' wikis are shredded for good. Mader provides some really good examples of corporate wikis in companies, such as IBM, SAP, Sony Ericsson, Pixar, Carbon Five and Red Ant, in his blog post, "7 Effective Wiki Uses and the Companies that Benefit from Them". Another extremely innovative approach to corporate wiki usage can be explored closely in a Slideshare slideshow, presenting the wiki-based intranet solution of a company called Avenue A/Razorfish, working in numerous digital areas, including advertising, web design and development, and building of intranets and extranets. The slideshow is definitely worth a close inspection, as it encompasses almost all key features related to creating an emergent information environment.


Sage Advice on Wiki Adoption: Keys to Success

So now to the advice on wiki adoption. Wikis, despite being very easy to use and edit, might face significant barriers of adoption. For example the unusual openness might pose a major challenge for many users. Publishing your ideas and opinions for others to read, edit and comment may at first seem very threatening. Also, the potential technical barriers are not to be underestimated. Usability of the application, structure of the content and the user's technical skill limitations have to be taken into account. Furthermore, community culture, in relation to information sharing, plays a key role in the adoption process; closely knit communities are more likely to adopt wiki guidelines successfully. It is important to provide clear and distinct guidelines for the wiki usage and plan the implementation carefully.

Tommi Rantanen explains some key adoption strategies in his executive summary, "University 2.0 - Enhancing Communication and Collaboration in Universities":

The best approach is to foster grass-root level's efforts and give top-down instructions after the initial efforts have succeeded. The bottom-up method is vital in convincing the tools usefulness and in adjusting the software to meet the actual needs of the employees. First the key user groups have to be identified, that is the groups which would benefit the most from the new software (Charman 2006b). The software is suitable if the group's daily aims and information flows are in line with the software's capabilities. Examining the key groups reveals the key users, who are the most important part of grass-root level implementations. A key user is a person who benefits most from the software and it can easily be implemented in his or hers processes. The key users have to also be interested in new software and socially well connected - influential among peers, highly connected and as a part of the major information flows (Charman 2006b).

Management's role can also have a significant influence on adoption success (Charman 2006b). After the training phase comes into action, the management has to support the training and additional emergent behaviors in acceptable amounts. Emergent behaviors mean for example that a wiki can be used to plan an informal recreation day. In addition the managers should be willing to act as an example by adopting the tools along with early adopters.

(...)

By deciding clearly what functionalities and specifications the system will involve, the system will become easier to comprehend. The early specification and simplicity will make inertia less likely and also lessen the probability of misspecification. Misuse and nonuse are very challenging pitfalls since they depend much on the user group's attitudes. If the new technology is not seen useful and it doesn't seem trustworthy companion, misuse and nonuse are likely to emerge. Misuse occurs usually when the users are not familiar with right methods or want to prove the system's impracticality (McAfee 2003). Nonuse can also occur alongside resistance. This is most likely to happen when people are concerned that the new system will eventually take their jobs or transform their duties into something less desired. Resistance can also be present when the new system is not seen useful enough.



The next section is a conclusion of Maders blog post, "Sage Advice on Wiki Adoption: Keys to Success".

  • Selecting the wiki software has to be done carefully
    • The software should support future changes and have an active developer ecosystem to ensure updates and extensions
    • More...
  • Start with what you already do
    • For example keeping the meeting minutes in the wiki.
    • Plan agendas using a wiki
  • Adoption of a wiki is best achieved when predicated on a "want", not a "mandate" 
    • Problem with mandates: Usage often drops after the initial push is over
  • Start a small pilot group
    • Gives a chance to spend a meaningful amount of time working with them to look at their existing work habits, develop ways to use the wiki to simplify collaboration, make tasks and processes more efficient, better documented and faster, and ensure lasting success
    • First group a success: they'll tell their colleagues and support them in their initial steps
    • Reduces the IT department's work load
  • Include senior leadership, a high-level, well-respected leader to take part in the project right from the beginning
    • This builds the leaderships confidence and gets them involved
    • Adds legitimacy to the wiki
  • Find the Champions
    • Encourage them off and on line to continue and mentor others
    • Key to building a network of people using a wiki professionally
    • Beware of Bullies
    • Beware of Do-it-all behavior
  • Practice what you preach!
    • If you advocate wiki use, make sure you're an active wiki user.
    • Set example in order to inspire and engage others!


Sage Advice on Wiki Adoption: The Pitfalls


A conclusion of Mader's blog post, "Sage advice on Wiki Adoption: The Pitfalls":

  • It is not a new place to put work, it is a new way to do work
  • Let people step forward
    • Overactive security models, excessive taxonomy, and extreme management oversight will turn your wiki into nothing more than the magnificent inflexible shell you originally created
    • Critical mass will be impossible to achieve unless people are willing to step forward on their own
  • Give guidelines, not rules
    • Keep in mind that too little guidance will result in too little activity, because it only appeals to the most self-directed people.
      • We paint lines on roads for a reason
  • Avoid adjusting too much structure



21 Days of Wiki Adoption

Mader has put together a great collection of video tutorial episodes covering different aspects of wikis and the adoption process. This is probably one of the most comprehensive collection of concrete advice and "tricks" to promote the appropriate use of wikis in companies. The tutorials can be viewed at "21 Days of Wiki Adoption", but I have also summarized key content here into text form. Some of the key points are linked into corresponding sections in Wikipatterns.com, where you can find additional information concerning the subject.

  • Don't mandate the wiki usage
    • Let people find out themselves where the new tool is most useful
    • People respond best when they see their peers using wikis and benefiting from it
    • Once a few people begin to use the wiki, they often realize that they could be even more efficient if only their colleagues were using the wiki too.
    • Highlight good examples of usage or content
      • Link to them from the wiki main page.
      • E.g. regular company newsletters are a great place to mention the examples.


  • Wiki vs. email
    • Email mechanics very complicated
    • Wiki certainly more easier and quicker to use in collaboration without all the saving and sending (and waiting for the other person to edit, save and send) of documents


  • Wiki isn't necessarily Wikipedia
    • Contributors in your organisation are not unknown people
    • Collaboration, not publishing
    • Users are usually members of a certain tight group
    • Organisations may also have a wikipedia type encyclopedia but that's only one use


  • First step to start a wiki in your organisation is to run a pilot
    • Lets you develop the appropriative addministrative support structure especially in the IT dep
    • Shows you the inevitable difficulties that arise in such a major project
    • Don't pick just early adopters
      • Other people won't give weight to hearing the success stories from early adopters since they know how much they love new technology
      • Others will, on the other hand, give weight to hearing it from initial sceptics
      • Develop success cases to show others
      • The pilot group will become evangelists and a support group


  • Barnraising ** Get your team together
    • Everyone comes to the initial meeting about starting wiki use in your team knowing that no one else knows any more about the subject than they do
      • They won't just stay quiet thinking that "I'll let other people who know better do the talkin and become the designated wiki person"
      • Everybody should become involved
      • Everyone can make decisions about wiki use together
      • Allows everybody to start adding to the wiki at the same time
    • Create the barn raising minutes in the wiki
    • Collaboration will get going as people have already invested their time into it
    • More...


  • Don't rush it
    • Don't try to force it right away to everybody
    • All wiki all time not the best way
    • Better:
      • Make them use the wiki for some / several different things and let them discover new uses themselves
      • These are much more likely to stick
    • More...


  • Better meetings
    • Meetings are the core activities in most groups
    • People tend to call meetings for small "stupid" reasons
      • Employees end up sitting all their days in meetings
      • Meetings not well structured
    • Feeling of not getting anything done
    • Wiki can improve information exchange in the group
      • Makes meetings shorter and focused on the crucial things
      • Wiki can be used for things like giving people updates on the status of projects


  • Meeting agenda
    • Send an email with a link to the wiki with the agenda
    • If you send an email with an attachment and somebody needs to edit the agenda, this creates a whole lot of more work and email flying around
    • Wiki always up-to-date
    • More...


  • Meeting minutes
    • Same page as the meeting agenda
    • Involve everybody in recording the meeting minutes in the wiki
    • Now that you have the minutes in the wiki this also makes it much easier for people to continue using the wiki for recording tasks, action items etc, which again is important for the next meeting


  • Action items
    • Most important outcome of all meetings
    • Create action items on the same page as the minutes
    • When u send an invite for the next meeting remind everybody to check the action items
      • Helps to concentrate on the essential things in the meetings


  • Project management
    • Action items usually just individual tasks that link to larger projects
    • Create a wiki page for each project
      • Links to the items included in the project
      • Also move other items, such as documents, that need collaboration away from emails and into the wiki
      • Future meeting pages can now have links to the pages that have critical content concerning the project


  • Documentation
    • For example writing a users guide for a product in a wiki
      • Table of contents on the main page
    • Links to pages that have the content
    • Now a group can write the different parts of the document
    • Once you are ready to export the document, you can easily export it as for example pdf
    • You can also just let customers access the wiki based guide on the internet
      • Customers create more information
      • Someone on the team has to monitor the wiki
    • Guides in the wikis are usually more up-to-date than the once printed the day the product was actually produced


  • Wiki vs. Content management system
    • Should the wiki replace other tools
      • Initially should just live alongside other tools
      • Let it complement other tools
    • CMS takes too long to get updated content online
      • Could a wiki replace this?
      • Prob not as when somebody is editing the wiki, s/he would be editing the live content powering the website
      • Instead you could just copy all the content from the CMS to a wiki and make different people responsible for different sections and now people can edit the wiki pages and once the pages are ready they can just notify the people responsible for CMS that the page is ready for being published
      • Great way for two tools working alongside each other


  • Security
    • Is a wiki secure?
    • Data ultimately stored in your organization's database which is much more secure than e.g. a laptop
      • Laptops get lost
    • Data stored in data centers much more secure
      • Take only the data you really need with you on your laptop
      • Wiki is also a good back-up copy
        • Your laptop not the only place where the data is stored
      • Version history


  • Afraid to share?
    • "If I share what I know on the wiki, I will become expendable"
    • On the contrary
      • Now also others know that you are an expert on something
      • Others are more likely to come to that person for advice
        • As this happens people who are afraid to share see that this actually makes the organization more dependent on their knowledge
        • Now they actually need to put more of their knowledge on the wiki since people are contacting them more. This frees time to do their own jobs
        • Now they have shown their value to the organization


  • Permissions
    • How open should my wiki be?
    • How do I edit the permissions for wiki spaces or pages?
    • For example you need to write a press release
      • First you draft it on the wiki, giving only yourself permission to the page
      • Then you invite few of your colleagues, give them read and write permissions
      • After the release is ready, you can send it to the pr for it to be printed and also make the initial wiki page open to everybody, giving only read permissions since a press release is a one-way medium
    • Team space
      • Making it as open as possible
      • If you don't do this initially, it will be very hard down the line to start reviewing which pages should be open after all
      • Only restrict what needs to be closed
      • If the information can be made public, make it public since this may further reduce eg. emails as other people are able to access the info on the wiki


  • Request procedure and retention policy
    • Formalized procedure a great way to manage growth
      • A web form for example (name, email. phone number of the person responsible for the wiki space), general use of the space, and is it permanent or just ad hoc for a single project
    • Now it makes it easy to have a retention policy
      • For example the people responsible for the wiki space of a permanent project can be sent an email (automated) after a year asking whether the space is still in use or not
        • If they reply yes, they get an other year
        • No - you can archive the space and delete the space
      • Ad hoc space, initially just for e.g. 2 months
        • Same procedure after the two months
    • Helps to plan the capacity
    • Enables to have a working retention policy to prune the wiki


  • Wiki Charter
    • Guidelines for good conduct
      • Especially if the wiki is made public
    • E.g. SonyEricsson wiki rules
      • Respective use
      • Take responsibility
      • Stay on topic
      • "If you cross the line you will be kicked out"
      • Use common sense
      • Don't take the info on the wiki as an official position of the company
      • Use English
        • Stay neutral when providing content
    • Beware of Copyright infringements
    • Beware of Pre-wiki behavior in the wiki
    • Beware of Vandals
    • More...


  • Be firm
    • Once the wiki is up and running don't let people fall back into their old working habits, email etc.
    • Important for the success of the wiki (and the group)
      • Value of the wiki is that every member of the team uses the wiki, not just some, since this only leads to division on information


  • Incentives and recognition
    • How to reward people for their contributions
      • Presents
      • Recognitions for people in e.g. management meetings
        • People are confident that the management is actually aware that they are using the wiki and actually encouraging the use
      • Build recognitions of wiki use into employee evaluations
        • Trickier to carry out
    • Cultural shift
    • Usually people evaluated for something else, like how many products they sell
    • Wiki Gardeners need to be noticed and praised
    • Beware of going too far in the recognition for wiki contributions


  • New way of thinking of people as knowledge workers
    • Contribution to the company important in the long term
    • When an old employee leave they take info with them
    • Documentation important
    • This starts by letting them know that it's a part of their job descriptions and evaluation
    • More...


  • Science fair
    • Get everybody share what they are doing in the wiki in a "science fair"
      • Posters and presentations
      • People learn new uses of wikis from others
      • It inspires people as they get to see how wide-spread the wiki really is




Additional instructive tips at Wikipatterns.com

  • A very important question is whether to impose structure, group the pages by creating "team spaces" or just count on structure emerging over time
    • Be sure to read the comments posted by the readers, as they provide additional opinions on the subject.
    • Read More...
  • Create a New Starter system to help employees to get familiar with the wiki
  • Create a FAQ section for Frequently Asked Questions
  • Notice possible cases of "Wikiphobia"
  • Establish a Community Portal in the wiki to engage people
  • It is critical to attain "Critical Mass", as otherwise the wiki may fall into dis-use
  • Wiki can also include the Corporate Directory containing employee information
    • Staff can instantly update their own information, so the process doesn't have to be centrally managed
    • Read More...
  • Use of content as "Magnets" to the wiki
  • To ease navigation, simple Naming Conventions may be in place
  • Create templates
    • People often respond better (and contribute more easily) to a page with a ready-made structure than one that's completely empty and unstructured
    • Read More...
  • Add a page for a discussion between the page's contributors (discussion page)
  • So who should pay for the wiki?
    • The groups using it, according to the amount of disk space and bandwidth?
    • But wouldn't this be punishing them for the thing you are trying to make them do?
    • Read More...
  • Is wiki space / page customization preferable?
  • To what extent is manager control acceptable and beneficial?
  • In large organization the wiki might end up becoming "crowded" as more and more various content gets published in it.
    • Is there a good way to deal with this anti-pattern?
    • Read More...
  • What about when people are afraid of editing other people's articles, thinking they might be offended
    • Rather they write emails or comments or offer their input to the author over lunch
    • This is not efficient wiki conduct
    • Read More...
  • How to cope with a situation where wiki usage is low and even rigorous personnel Training efforts don't seem to work?
  • "Branding" the wiki correctly may be problematic, as everything suddenly seems to a "wiki-thing"
    • Remember, it's not about the wiki itself, it's about the new efficient way of working and collaborating
    • Read More...



See also