Wikis have come a long way in the last few years as a flexible and user-friendly knowledge management tool. With due diligence on the company's information needs, good information architecture design, and teams' collaborative attitude, wikis can make teams collectively smarter, more agile, and more productive.
When wikis first gained popularity with organizations several years ago, they were often seen as a miracle cure for many corporate communications ailments. A no-fuss intranet, a way to get rid of email overload, the cure to a lack of document management, you name it.
These expectations, however, often were not accompanied by proper due diligence, good design or information architecture, and the tools weren't always the most user-friendly. This led to a lot of abandoned, half-empty wiki projects as corporate employees went back to living in their inboxes.
Fortunately, like many web-based tools, wikis have become easier for people to use and better integrated with other internal systems. They're becoming seen more as a tool in a balanced corporate communications and collaboration toolkit, rather than an all-purpose solution.
Wikis want to help
What are some of the activities to which wikis are well suited in organizations?
- knowledge base/how to documentation
- version management for documentation
- multi-author files
- project management
- research notes
- prospect/client notes.
Most fundamentally, wikis are a tool for recording and storing information. This may seem obvious, but is a critical function still handled poorly in many companies. Notes on paper, files on computers, reviews in email, verbal conversations... If information gets recorded at all, it's often in disparate formats that can't be easily shared.
Valuable knowledge residing in people's heads can get missed in constructing the big picture. Data doesn't get updated to the most recent and timely versions. Nuanced client information doesn't get considered. This handicaps organizations from making the best decisions and implementing best practices.
Wikis' value for recording and storing information is further enhanced by the fact that they are designed to facilitate collaboration. Multiple people can contribute to many wikis, one wiki, or even just part of the same document. One person can't accidentally and permanently overwrite or "lose" others' work. And the people using the wiki can be anywhere in the world. Geographical distribution is of no consequence to working as a team. With Igloo's email-enabled wiki functionality, team members can even start new wikis by simply emailing content to the relevant channel email address.
Wikis are also a very flexible tool. They are nearly infinitely extensible. They are as useful for simply recording initial brainstorming and ideas as they are for maintaining documentation over time or managing projects through their life cycles. Many wiki systems can display any document types that can be displayed in your browser. Access to the content and permissions can be customized depending on who needs to read or edit.
Wikis like Igloo's offer several very handy social features as well. Users with appropriate permissions can both edit the content directly, or leave comments about it. They can make in the article or in comments to draw another person's attention to specific material. They can also rate the quality and relevance of the content, providing structure for needed improvements or updates.
With good information architecture design, wikis can clearly present easily navigable, editable, and shareable content to a wide audience. Templates can help keep the information consistently presented and encourage inclusion of all relevant details. Could be information about client relationships, project status updates, weekly reporting, or benefits policies. Information can be updated any time by anyone with the right permissions, and changes can be reverted if someone gets a little overzealous with the delete button.
Having one or more administrators for your wikis is important on several levels. Someone needs to manage getting people set up, setting permissions, help with issues, etc. However, a consistent and steady hand is also needed to keep the content tidy. This could include functions like:
- helping teams create templates for content types to ensure consistency and comprehensive information recording
- helping determine what the best metadata is for the content (descriptions, labels, etc.)
- orchestrating updating of older content so versions are current
- pruning and archiving old, no longer relevant content
- preventing excessive editing by multiple disagreeing parties.
Wikis can also help companies with the ongoing challenge of retaining domain knowledge. The longer people work at a company and particularly the more specific their roles, the more mission critical their accumulated store of knowledge is. But change is constant, and people go on vacation or get new jobs. Work needs to get done even without them, so it makes little sense for essential data to remain only in their heads.
By recording key information about people, processes, and projects, everyone who needs it has access to domain-specific knowledge, and roadblocks to getting work done are removed. Now, in some cases there are security or privacy concerns about the information, but again, that's what access permissions are for. And with customizable notifications, when the wiki is updated, relevant parties will be, too.
Services like Igloo enable you to roll-up multiple wikis into one view, making it easier to distribute permissions (to read, write, and edit) while presenting content to your users in one spot. For example, if you have regional offices they might each have their own benefit policies. You can create a wiki channel for each region, each with its own authors and audiences. You can bubble-up that content on a main "policies" page, merging with corporate-wide content. Users will only see content they have permissions to, making it easy to show (or hide) region-specific content.
Making this information accessible is also incredibly helpful when new people are brought on board. They're likely to have endless questions, and a quick search to yield the required information is much more efficient than trying to hunt down "that guy".
What are some of the benefits of wikis?
We've looked at some of the ways wikis can be implemented in organizations, and touched on a few potential benefits, but there are broader potential gains. One could even suggest culture-shifting ones. Such as?
- prevent excessive email
- centralize reporting
- centralize feedback and review cycles
- provide better orientation for new people
- prevent document or data loss (and encouraging better security) by keeping them out of personal directories, email, etc.
- provide an additional facet for performance review
- provide a user-friendly, highly useful first iteration of a corporate intranet (especially with a modular solution like Igloo's).
That's a tall order, but it is possible. Of course, as with launching a new community, a wiki ecosystem is best rolled out in staggered fashion. Start with a team that's amenable to trying new tools, and, ideally, has lots of knowledge to be recorded. Invest in team interviews, knowledge and data audits, and information architecture design before anything is actually created. It saves a lot of headaches to do things right the first time rather than having to go back and clean up or retrofit the system.
Centralizing functions is as valuable from a cultural standpoint as from a process one. Certainly it makes sense to have all the up-to-date information accessible in one place, for all relevant parties, with clear change records and input recorded. But centralizing knowledge management also helps create a mental shift in team members as well.
A single location containing all the work where it's obvious that multiple people are collaborating helps shift mind set from "mine" to "ours". People start to think explicitly about the team's projects, data, and who needs to be aware of what, rather than my projects and data, and "I have to do it all myself," which tends to build silos and break down team work.
From a management or security perspective, centralized knowledge management provides much better audit trails and data security, as it's clear who created documents, every change that's been made and by whom, and (ideally) the documentation only has that single home in the wiki. This is as opposed to many versions stored in email and on desktops, etc., which is a security (and version) nightmare.
The type of wiki software is also of interest to IT and security teams. Many wiki apps are built on open source code from third-party vendors. This requires a number of considerations for security, integrating the software into existing systems, and maintaining the tools. Modular solutions like Igloo's wiki app are built as part of an integrated system, and work seamlessly with other parts of the intranet, as well as a variety of other common systems and tools.
In the same vein, documentation that requires review by multiple people gets the same treatment. Who has accessed it has been recorded, as is when it was last updated (e.g. for weekly reporting), and what was changed. As organizations become more and more data-driven, it's important for all relevant parties to be on the same page when it's time to review projects and make decisions.
Employees' collaborative efforts can also become a consideration in performance reviews. Certainly some roles are more independent than others, but someone's ability and willingness to contribute to the team or company's collective knowledge base says a lot. How much content have people created? How much have they edited? How often and on what topics? Have they done it unprompted, or do they have to be reminded to use the tools?
When to wiki?
At first glance, it can be difficult to determine the significant differences between assorted content creation and management tools. For example, does it matter when you create a blog post as opposed to a wiki? It can, yes. Some examples:
- Blog posts are generally intended to convey more time-sensitive information. Wikis are intended to be in use long-term.
- It's okay if blog post's content becomes obsolete over time. Wikis should be maintained, the information is meant to be kept current.
- Blog posts aren't really intended to be edited much after publication. Wikis are intended to be "living," regularly edited documents.
- Blog posts can be more casual or conversational in tone, and can be used for social or cultural as well as informational purposes. Wikis are more intended for formal documentation and knowledge management.
- Blog posts can have multiple authors, but more commonly are written by one person. Wikis are intended for collaboration by as many people as needed.
- Blog posts are good for news and updates, but the actual policies or documentation they refer to are better recorded in wikis.
Additionally, while many types of content in organizations benefit from multiple sets of eyes during creation, review, or updating, not everything needs to be done collaboratively. Sometimes the person creating the documentation is the only subject matter expert. Or sometimes the number of eyes on the content needs to be restricted for privacy or security reasons. Again, this is where the flexibile permissions are convenient.
Wikis have come a long way since their early, misunderstood days as a possible cure-all for organizations' knowledge management needs. They're easy to use, flexible in what types of content and collaboration they support, and can help shift cultural norms so employees embrace better productivity and teamwork. Wikis are a great modular part of an overall intranet solution, and with a little guidance, and be a very powerful way to record, manage, and maintain an organization's information.