- 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.
- Blogs and forums preserve voice and authorship. Use them where knowing who said what is important.
- 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
- 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.
- 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.
Pingback: Knowtu » links for 2010-02-23
Pingback: SKMurphy » Matt Perez on How Nearsoft Leverages Yammer
Pingback: SKMurphy, Inc. Delegation Needed For Growth - SKMurphy, Inc.