Monday to Wednesday, 10am - 4pm, ET
1.855.281.5499 (toll free)

Does your nonprofit have turnover in volunteers or staff that sometimes results in lost organizational knowledge? Do you have remote staff or volunteers emailing each other for basic instructions or process guidelines? Does onboarding new staff or volunteers take time because instructions can be hard to remember or documentation becomes easily outdated?

If you’ve said yes to any of the above, then your nonprofit needs an internal wiki! As Lifehacker explains in an introductory wiki how-to article, “whatever your job, chances are good that you could use a wiki.”

Like Wikipedia, wiki technology can be used internally by any kind of organization to document, organize and easily share important knowledge. The use of an internal wiki can really improve organizational efficiency and knowledge management if it is well-integrated into the daily work of staff, remains up-to-date, and is easy to navigate.

While it’s easy to understand why a large organization would need to centralize their knowledge documentation, these benefits apply to small organizations as well. Resources for small organizations and nonprofits on the topic can be hard to find, and so this article aims to help fill that gap by sharing TechSoup Canada’s experience of revitalizing our small team’s internal wiki. At the end of the article you’ll find a few useful tips and links to get you going if you’re setting up a wiki for the first time.

How We Revitalized Our Staff Wiki at TechSoup Canada

We are a small team running a fairly technical operation. There are a lot of processes that occur only on occasion, and there are repetitive manual back-end tasks that require a lot of detailed information to execute. We also need to be fairly cross-functional, for example to cover other staff for vacations.

Here’s how we updated much of our documentation and then integrated wiki use into the (almost) daily workflow of every staff member.

1. Assessing the Situation with A Basic Knowledge Audit

I adapted some basic principles of knowledge management to our small-team context:
  •  Take Stock: First, I took stock of our current knowledge documentation. We had files and instructions stored in the cloud through Google Drive in lots of formats, several different wikis on different topics that were in various stages of completion, as well as all the knowledge in people’s heads.
  •  Staff Survey: I then surveyed staff about their use of our current wiki(s), if there were documents they used outside of the wiki for instructions, and their vision for the wiki use as a team. There are only 8 of us but the survey allowed me to get information that might not have come up in a meeting or casual chat about the project.
What did we uncover during the “knowledge audit?” First, that training on the technical side (editing and updating pages in the wiki) was needed. As well, some staff documented processes and updated pages more than others. Only a few staff regularly used the wiki, and it was not easy to know where to search for information. Lastly, we realized that it would be easiest to create a new wiki where we could have a clean start, rather than trying to fix one of our old wikis.

2. Creating a Team Vision and ‘Evangelizing’ Wiki Adoption

In my wiki research, I came across advice to encourage adoption of wiki use and effective knowledge documentation, a challenge we were evidently facing. As this article on enterprise wikis suggests, we needed to “evangelize wiki adoption.” 

And so, I set out to ‘evangelize’ just how great our documentation could be really be. The results, I explained, would include improved collaborative knowledge management, enhanced role cross-functionality, and would, overall, make our small team more agile.

How did this phase work?

  • Set Standards: We decided at a portion of a staff meeting what what should and should not go in the new wiki: we wouldn’t use a wiki for working on projects or storing dynamic information. For anything that changed regularly, we would use the embed feature that allows you to view the content of a basically any google document/sheet/drawing, etc. or to view other webpages. The goal wasn’t to put everything we’re working on in the wiki, but to document our work and processes across the entire organization.
  • Make (Almost) No Rules: We made no rules except that one should not delete a page they didn’t create unless they were sure it was irrelevant. The structure and method for making or updating pages would rely on common sense and team trust, making it easy for staff to document knowledge within the wiki in the way that works for them. (A search feature helps us find things, as does a layered menu as you’ll see in the image below, so it’s altogether low risk. You can also find things that were erased and see recent changes.)
  • Collaborative Team Training: We dedicated a portion of a staff meeting to working together to learn all of the basic features of building Google Sites, making sure we shared our acquired knowledge with each other.

3. Updating and Migrating Documentation to the New Wiki

Next came the grunt work of moving and updating information all into one place:
  • Use a Project Tracker:  We used a Google Spreadsheet with the menu outline and all the page titles that needed to be updated and moved. We used a column to mark if it was up-to-date or needed work, if it had been moved yet, and who moved it. This same format would work for reviewing files, or for creating pages on a certain topic. A simple cloud-based tracker is a useful tool to manage the project generally.
  • Move the Good Stuff First:  One person (me, in this case) went through every page in all of the wikis created over the past few years and assigned them a status (up-to-date or needing work). As the head “wiki gardener,” I made sure to move anything that was in great shape in advance of asking the others to join, making it easier for the rest of the team and building momentum.
  • Collaborative Updates: After the initial review was finished, the rest of the staff dived in, reviewing pages in their area of expertise, updating them, and moving them into the new wiki. The process took a few weeks and seemed to more or less manage itself! Staff members also took the initiative to add sections they identified that had been missing from previous wikis.

Several months later, the end result is a wiki that is up-to-date, continually growing, and used by all staff members very regularly. It is also maintained by the whole team, not just one or two people “wiki-gardening.” As we train on cross-functional tasks now, we can easily share links with detailed instructions for each new knowledge area. A follow up survey of the office confirmed that the whole team is now creating and updating pages when needed, has the knowledge to do so, and overall  we are finding it easier to search and navigate through our information.

Bonus: Embedding Documents & Websites into your Wiki

To conclude this article, I’ll share this cool side note: we’ve also been able to include dashboards displaying organizational information from all our different data sources into our wiki using the embed feature of Google Sites (see the image below). We have documents, spreadsheets, external websites with our email open rates, and charts and graphs from Zoho reports, all embedded into the wiki. The current wiki functionality really surpasses anything I thought I would come out of the project and has been very useful for the team in keeping up to date on what’s going on in our dashboards.

How to get started for first-time wiki builders

How can your nonprofit get your own wiki set up? Here are a few tips from our experience:

  • Start learning by reading this great article by Idealware. It’s a few years old but much of it is still relevant. It goes over the basics of what a wiki is, why it would be useful for your nonprofit, and tips for getting started.
  • Get buy-in from leadership and perhaps more importantly, from the team who will be using the wiki. Here’s a few more benefits of a wiki to give you ideas.
  • Select a tool to host your wiki. We used Google Sites, which is available for free to nonprofits through Google Apps for Nonprofits. Here’s a basic video that explains how to set up a wiki with a Google Site (geared at teachers). Another option is MediaWiki, the open source wiki platform used by Wikipedia.
  • Select a “wiki gardener”. Idealware explains this role: “it’s best to choose one person to oversee the organization of the wiki as it grows. This will be an ongoing, active role—your original outline will be a good start, but because wikis allow many to contribute, things will tend to stray from the plan from time to time. The person who does this work, trimming one branch of content, planting the seeds for what will turn into groups of pages on particular topics, is called the wiki gardener. Really!” Here’s another article to help you learn more about the tasks of a wiki gardener.
  • Build a culture where everyone feels a sense of ownership of the wiki. This is an ongoing task that will need a combination of good ground rules that everyone’s aware of, team training on how to use the wiki, and lots of reminders! For example, remind staff to search the wiki first if they have a question and go through the documentation with them, or remind them to update the wiki if a process is changed.

A wiki may take a bit of up-front work to get going, but the end result - an up-to-date resource and a culture of keeping the knowledge fresh - is valuable for any nonprofit and well worth the effort.