The Case For Project Wikis

There are a zillion tools out there, built to help keep project teams and material organized. It’s easy to get bogged down in a sea of shared documents, all living in separate places. Even when a filing system exists, remembering where information is stored can be exhausting. Is it in Google Drive? Did someone share that with me in Slack? Or maybe it was posted in Basecamp? It’s no wonder that despite every project manager’s good intention, the inevitable ends up happening: the organizational system goes out the window and you resort to one-off sharing of links over, and over, and over, and over again.

Or, people just stop trying to find things. And those carefully formatted meeting notes, in the nicely labeled folders, on that shared workspace might as well be a black hole.

Knowing this pitfall, and experiencing it on my own projects, I needed to find a different way to share information with my project team without reinventing the wheel. I started using a “project wiki” system for centralizing project material and information. Not only has this helped my team to have one single place to go to for everything they could need, it’s helped me stay aware of what types of information is worth documenting in this way.

What’s a Project Wiki?

At its core, a project wiki is a centralized place of reference that speeds up the process of locating project information and material. Structurally, a project wiki should have organized collections of information that are kept up to date as the project evolves.

A project wiki can be comprised of lots of things, but there are four basic sections that I have found to be the most useful.

Quick Links

A quick links section is the place for resources you refer to for the entirety of the project. These should be links relevant to everyone on your project team. They should also be links to things that will remain static throughout the project so you don’t have to worry about constantly updating this section.

Some of my essentials include:

• Shared workspace
• Google Drive folder
• Contracts and budget sheets
• Status report
• Timeline

Working Files

Here is where your team’s working documents go. Any time a team member shares something for group review, it goes to this section for posterity. This list should be kept relevant to the engagement at hand and should be updated as new versions necessitate. I think of this as the list of files I would need to reference to build the final deliverables for a project.

Decks & Meeting Notes

Keeping meeting notes and presentations in a single folder can be a pain, especially on projects that have distinct (and sometimes separate) phases where related material may be stored in a place specific to that phase.

Listing meetings in chronological order has worked best for me. In addition to the presentation deck and meeting notes document, make sure to include any supplementary links referenced in the presentation.

Client Provided Materials

This does not have to be an exhaustive list of everything the client has provided and can function similar to the Quick Links section. You can also include links to entire folders, websites, Basecamp posts—anything that the client has referenced and is important for your team to be able to access quickly.

Using Slack Posts as a Wiki

Where you create and maintain your project wiki is as much of a function of personal preference as it is the tools your team uses. At Viget, we have a Slack channel for every project; Slack is essential when working with teams across our four offices. It’s the one tool every single team member uses so it felt like a natural place to house my wiki.

Utilizing the post feature in Slack, you can create a native post to your Slack channel. Posts can be shared directly with Slack users or channels and can be starred or pinned for easy locating. Perhaps the best thing about Slack posts is that they open up in a separate window when editing, as well as expand inline when being viewed in a channel. This eliminates having to open any additional applications to get to the information you’re looking for.

Wiki Tips

Staying disciplined is always the challenge when creating and maintaining any type of organizational system. When creating your own project wiki, keep these things in mind:

• Pick a tool you’ll gravitate towards using to make building this habit easier. Tools that are widely adopted by the people you’re working with is also an important consideration.
• Focus on reducing the number of clicks required to get to any one file. This should hopefully encourage adoption of the wiki from your team.
• Wikis can also be a great resource to support project on-boarding or team transitions. Make it easy for new team members to get familiar with basic project knowledge and the work that has already been done so they can hit the ground running.
• Consider if your client would also benefit from having a wiki. Organization can be hard for clients with multiple priorities. Creating a shared project wiki is one way to help client’s keep track of the project.