Use Wikis for Team Projects

February 23rd, 2010 Sean Murphy

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.

Entry Filed under: Blogging, Rules of Thumb, skmurphy