Wikis are a great tool for managing shared information among many people. As a collaborative knowledge base, a wiki gets more useful as more information is available on it…but getting started isn’t always easy. This blog post will review why wikis are useful, how different types of people use them, and how you can start or contribute to one yourself. Please add your own advice in the comments.
I get Wikipedia, but Wikis for work?
Wikipedia has the reputation for being a source of all knowledge and an unreliable source of incomplete or biased information. When the world can edit the popular encyclopedia, it is open to both corrections and erroneous content. Ultimately, it’s a repository of the shared and verified knowledge of all people who can and do edit it. It’s flexible and usually up-to-date.
Translate that to an office: an office wiki is a repository of the shared and verified knowledge of all people who work together towards a common goal. It’s the ultimate knowledge base. Its structure and function encourage updates, comments, and additions. And at any point in time, it can contain the most up-to-date information about projects, people, and systems. Information that’s otherwise stored on desktops, in emails, or on post-it notes can be recorded, corrected, credited, updated, and accessed by everyone in the office.
This means that a new team member can get up-to-date information on a project without weeding through 100 forwarded emails. A new staff member can find out how to apply for leave. A two-days-a-week contractor can keep up on projects that continue on in their absence. An analyst or manager can be aware of all projects. A whole office can comment on ideas, prototypes, and designs, whether or not they’re specifically working on a project. This increases transparency and awareness, enabling synergy between the creativity and knowledge of all team members.
With a wiki, you can lock in and share knowledge so everyone on the team can focus on innovating and moving projects forward – instead of starting from scratch every time.
How do I start a wiki?
Starting a wiki from scratch? Lead by example. Think of all of the information that you have about projects, processes, and your office that you have stored in your email or in folders on your computer. What information would be most useful to your colleagues or team members? Starting somewhere is better than not starting at all. The next time someone asks you for something, send them a link to it on the wiki.
Just starting out on an existing wiki? Follow the leader. Take a look at what’s on the wiki – if you can add something to an existing page, do! If there’s something you have a comment about, post it! Are your projects on the wiki yet? If not, get your project information out of your email box – like contact info, meeting times, and meeting notes. Having them on a wiki will make it simpler for you and your team to keep up-to-date on a project, waste less time tracking down more information, and spend more time communicating.
Trying to convert others to being wiki users? Remind people to look there before asking about projects, processes, or documents. Make the wiki the only place to get team documents or calendars. Then people will have to go to it for information.
Wikis are social documents, and they do need editing. But don’t worry – the important information will stay up to date as long as people are using it. Be open to revision – people will make changes and have comments. be courteous and don’t delete pages, but do make additions, corrections, or comments. These can always be undone.
“Most wikis have a problem of stale information if you don’t nag people into using it as a central point. If you think of wiki pages as streets, alleys in a city, it makes sense. Alleys have less eyes so they become more neglected. You’ll always thus have some stale content.” – Dino Beslagic, Newsroom Web Developer.
Who uses wikis at work?
“As a developer it’s extremely useful to have a place to keep track of small commands, useful utilities, and ‘tools to check out at some point’ rather than sending all of those to your colleagues through emails.” – Joe Flowers, Developer
“It provides an easy way to get feedback on designs, wireframes and ideas, thus eliminating long email strings with feedback from a variety of sources. It also makes clear who is giving the feedback via commenting.” – Lynne Venart, Designer
“Using internal wiki’s provide a great way to be transparent and clear in communication with many parties involved, without spamming everyone through email, constantly interrupting them through status updates or instant messages and phone calls,” said Will Sullivan, the BBG Mobile Lead. “They also naturally provide a clear version history on documentation that’s track-able and help keep everyone informed as to what’s the most up-to-date information, which is especially helpful for tracking quickly iterating projects, like mobile, in which everything changes every 3 months. I personally love wiki’s because a well-maintained, properly cross-linked and clearly documented wiki is a way to create a second brain. And if you have a staff that supports and maintains their part of the wiki too, you can rapidly expand the combined knowledge-base and move much faster.”
New Staff or Team Members
“When I was hired two months ago, I was overwhelmed by URLs, acronyms and unfamiliar project names. The Wiki became my default resource for finding answers and making sense of the office. The ‘Welcome to the office’ post provided a convenient list of links to help new hires. The individual project pages helped me helped me have a better understanding of what each project was, what had already been accomplished and what the next steps were.” – Brian Williamson, Designer
Good Information for Wikis
Here are some starting points of information that you might want to put on an office wiki:
Note: Be aware of who has access to your wiki and be cautious about posting sensitive information in public places.
- Vendor contact information
- Important dates (rollouts, product launches, etc)
- How-to guides and documentation
- Project debriefs
- Contract and purchasing information
- Useful employee URLs and contact information (HR, Payroll)
- Welcome to the office information for new hires
Shared Documents, when a single version is better
- Calendars – vacation calendars, editorial calendars, management calendars
- Operating and escalation procedures
- Style guides (graphic and text)
- Regularly used graphics (like logos) and graphics guidelines
- Org charts, lists of websites, lists of products owned
Knowledge Base Notes, for the good of the order
- Configuration information for a tool you just set up
- Lessons learned and documentation
- Code snippets, shortcuts
“It helps keep everyone in touch and up-to-date on projects, in spite of limited work schedules and telecommuting, and as an archive of notes for a project, which can be accessed at any time by anyone. This leads to a more transparent workplace, because everyone knows what everyone is working on, and anyone with a contribution is welcome to comment or otherwise participate.” – Lynne Venart
- Team contact sheet and meeting schedule
- Planning documents and schedules
- Meeting notes and project updates
- Prototypes or in-process work for comment
What doesn’t belong in a wiki?
The two main users of wikis are information-seekers and information-sharers. Time-sensitive information, things that are out of date, and information that is not allowed to be updated are less useful on most wikis.
Draft copies of documents: Drafts don’t belong on a wiki – only the most current version of a document should be stored, unless the process of drafting is an important thing for your colleagues’ reference. Update, revise, or reorganize old information – pages shouldn’t disappear without explanation.
Time-sensitive information and alerts: You don’t seek out alerts – they should come to you. Unless you’ve specifically set it up a wiki to alert people, wikis should update with information that your colleagues can look to for reference, or can add to ad hoc. Don’t expect to communicate time-sensitive, critical information via a wiki alone.
Authoritative, un-revisable, documents: When authoritative documents are posted for reference, that’s fine. But consider that content on a wiki should be living - up-dateable and improvable. If old authoritative versions of documents or policies are really important to keep around and intact, a wiki’s probably not the best place for them.
What are the best practices for managing a wiki?
“My favorite best practice is to be generous in the use of tags so that it’s easy to browse content by subject category.” – Joe Flowers, Developer
“If you are in a meeting and someone starts taking notes on their notepad or on their laptop, use the wiki instead.
If you are going to open a word doc to take notes on your thoughts on how to approach a project, use the wiki instead.
If you are going to send project documents for review to your team via email, use the wiki instead.” – Lynne Venart, Designer
Add your own best practices and tips for using wikis in the comments section below!