Hi, I'm curious to know your experiences in using Wikis. We have been using wikis for positioning and messaging framework development, market requirement documents, presentations, and other documents. One thing I've been finding is more of a tendency to critique or offer comments versus true "co-authoring". One of my clients was sharing this same phenomenon today. Seems like some people have a general inhibition to jump in and co-author or change other authors' content. Have we raised a society of arm-chair editors? Has anybody else experienced this adoption barrier to true co-authoring? What other adoption issues have you faced in using wiki's to co-develop documents? I'd be very interested in hearing your experiences.
I have been in both Wiki and Sharepoint environments as document repositories. In all of these scenarios, people comment on a single author's work instead of co-authoring. I don't believe this stems from being arm-chair editors, but rather from the culture of having one owner of a deliverable and others as contributors. This is a direct fallout of the RACI model (Responsible, Accountable, Consulted, Informed) where only one person on a project should be responsible for creating and overseeing a deliverable. By definition, this makes everyone else reviewers and critics.
In Joint Contact we manage the function of "co-authoring" by linking content (such as documents, tasks and images) to discussion groups. As you've pointed out this allows teams to review and post comments in a single location. Documents and images that are linked to a discussion are also placed in a general project document repository. This allows important content to stay organized as more content is added to the project.
sounds like the toolset isn't the issue; the acceptance of roles (ultimately, the organizational culture) is the issue. if the organization operates on the model Don suggests, then you should expect this.
however, the RACI model strikes me as a bit dated and rigid -- very 20th century!
these days, agile programming, where people work in high-productivity pairs, is now widely accepted in contemporary dev shops; and I've frequently found the best working relationships with other colleagues (especially my marketing peers) to be especially productive when we co-author a variety of work products. a key prerequisite is people not having their egos in the way of ideas and expression; and a compensation environment that rewards collaboration vs. penalizing it, of course.
having just started a new gig, I'm just about to implement a Wiki in our shop for all the above reasons - following a specific request from my CEO -- which I consider a very good omen. I'll let you know how it goes. oh, yeah: since we're in Portland, it's gonna be Open Source all the way, baby!
Permalink Reply by Val on August 24, 2008 at 1:49pm
We use both SharePoint and Wikis for our development and collaboration efforts. We seem to get more 'editorial' in SharePoint and more 'collaboration' in the Wiki. One reason I think this happens is that the Wiki work comes after and/or during a scrum session and the sharepoint documents are created outside of a collaborative experience -- such as after a long meeting or in preparation for one.