Use Wikis for Team Projects

We have used wikis for team projects for 7 years. Here are some reasons why, lessons learned, and best practices we have adopted over time.

Use Wikis for Team Projects

1. Wikis dissolve voice and authorship. Use them where there are rewards and incentives at a team level, where a team is being held accountable for a result.
2. Blogs and forums preserve voice and authorship. Use them where knowing who said what is important.
3. Start with frequently updated information that is also frequently accessed:
   • Meeting agendas and minutes (avoiding the bottleneck of the designated note taker and/or overlapping amendments in different e-mails that then have to be reconciled),
   • Early and still evolving specifications
   • Project status in a dynamic environment
4. Projects end, products are shipped and end of life, problems get solved. At some point in the business world many wikis must be congealed into a document or document set and either archived, frozen as a static HTML tree, or transferred to a content management system where more formal revision and change control methods are more appropriate. Unlike Internet wikis, older project or product wikis are often better preserved as read only archives.
5. Wikipedia anchors a lot of expectations in a use case that is rarely appropriate to a team that is not building an encyclopedia. Hope that useful content will be curated in a general purpose wiki is unlikely to be satisfied.
   • Use many small team level wikis, each for a distinct project or purpose, where the team membership is clear and there are shared incentives for cooperation and success.

Related Blog Posts

• Ten Tips for Leveraging Blogs and Wikis in Your Consulting Practice
• Do You Use a Wiki to Deliver Services or Develop Content?
• Lunch & Learn: Using Wikis for Projects
• Using Blogs & Wikis for Better Collaboration
• Use Wikis for Team Projects
• Fantastic On-Line Workshop on Wikis at CPSquare in January 2009
• We Use a Wiki to Organize Customer Interviews