Ask yourself and your team the following questions before you start, and be truthful with the answers.
Think about the issue you are trying to solve, and then see how a wiki might be applied. Remember, don’t just focus on the positive, think about the potential negatives, too.
For any technology implementation to succeed, there needs to be a problem to be solve or an operational efficiency to be gained. Think about why you are considering a wiki. Do you have examples of wikis being used to address similar issues? Did they work? If so, why?
There are two ways you could measure success. One is by setting goals for the adoption of the wiki itself, such as measuring the percentage of the community contributing, the number of people registered, the number of new articles, or the number and frequency of comments.
The other way is to measure the wiki’s success based on its impact on your business needs. For example: Did the wiki reduce the time taken for a particular process? If the wiki is a customer-facing one, how many people visited certain wiki pages? Did the wiki reduce email traffic or the number of meetings?
One of the first questions asked about any new system is, “What is the financial return on investment (ROI)”? With wikis the software costs could be as low as zero for an open source solution or as high as several thousand dollars for an enterprise solution. Regardless of the software costs, the cost of populating and maintaining the wiki will probably be higher. The ROI may not be directly attributable to the wiki itself, but instead may come from a change in collaboration methodologies and operational improvements.
Before you start to consider the ROI on the wiki, you need to calculate what it actually costs you to complete certain business functions today, or how much the business issues you are trying to solve affect the bottom line. You need to know today’s costs before you can calculate what you will save tomorrow.
Meaningful content is the key to any successful wiki, so you need to think about where it will come from. While you may be looking for the community to contribute, you will most likely need to seed the wiki. Where is this initial content going to come from? Will you need to invest time in creating new content, or will you import existing legacy content, such as technical documentation, training, policies and procedures, or marketing materials? Will you need to integrate the wiki with an existing content management system? The needs of each wiki implementation will be different.
While you may be implementing a wiki to meet one particular business need, think about every area of the company, or community, that could benefit or contribute to solving that problem. Try to move beyond functional boundaries and think about the skill sets and the knowledge base of all who would benefit. In some cases this may include people located outside the organization.
Of course, one of the great things about wikis, and the central theme of this book, is that they foster growth and further collaboration. There are numerous examples of cross-pollination of wikis inside organizations as one team sees the benefits that another has gained.
Before you start your first wiki, spend some time thinking about areas of potential growth and possible future cross-functional collaboration. Make sure you make plans for scalable growth and allow easy access for anyone who may need to contribute or observe, not just on the initial projects, but on potential future ones as well.
Every wiki needs a wiki maven to maintain it, something I will discuss in greater detail in Chapter 6, Maintaining the Garden, but it also needs someone with a sense of ownership. Be aware of inherent “not my idea” resistance in championing a wiki implementation and be prepared to give up ownership – even if the idea was originally yours – in order to ensure implementation.
Wiki branding can also be an issue. You may need to customize the look and feel of the wiki to reflect your corporate brand. Many wikis allow a sophisticated level of customization and branding, so this should not be a difficult technical issue to handle.
The location and hosting of a wiki can be contentious and should be addressed early. In large organizations the IT group may want to host the wiki (or they may actively be against the idea). However, in certain circumstances it may be better hosted at a department or project team level or by a third party wiki hosting company outside the firewall.
Trends seem to indicate that bottom-up wiki implementations hosted by a department or project team are usually the most successful ones. In other words, it can be advantageous to “fly under the radar” in the early stages as you develop and build acceptance and usage of the wiki.
There are many different types of wiki in the marketplace. Don’t just decide to use one type because it’s the only one you’ve heard of. Go and do some research. Talk to people who have used wikis for similar implementations, find out what they used and why. Find out which wikis they rejected and why. Develop a short list of at least three wikis to prototype and test. See Appendix D: Notes on Popular Wikis for more information on selecting a wiki.
Arguably, the first rule of wikis is that there aren’t any rules. It is true that wikis function best when they are driven by the communities that use them, but you need to think about a few basics of control before you start:
Do you need logins, and if so who will authorize them? Will you need to hook the wiki up to an existing user base, such as Active Directory or another LDAP store, or will it be good enough to manage the users and groups entirely within the wiki? Will you have some sort of initial structure for your wiki content?
Will you give users a “sandbox” area to learn the wiki in? Who can see, read, and edit what pages? Who will monitor recent changes and do any necessary roll backs? What’s the philosophy for rolling back content and incorporating comments? You will find that these answers change and evolve along with the wiki, but it is good practice to at least set a baseline.
Answering these questions will help you build a model of expected behavior, benefits, and potential issues to be addressed before you start.
The next step is to take these answers as a baseline and start looking at both the good and the bad aspects of wiki implementation in more detail, while considering the overall question, why use a wiki?