Structured Collaboration, Wikis, and Getting the Job Done (part 2)

Now, let’s narrow this down to technical documentation, shall we?

Online collaboration is needed for various steps of the technical documentation process. Authoring and editing documentation can be a collaborative process, for one. Reviewing documentation, obviously (you saw that one coming, did you). Getting user feedback on released documentation is another one.

On authoring and editing, documentation team practices can be translated either to open collaboration and structured collaboration. From the wide open practices of O’Reilly (see the Open Books Project) to the one-writer-per-documentation process, the way companies do their documentation business is what is going to translate into the optimal group collaboration solution.

On getting user feedback, Wikis are definitely a seducing approach for a business collaboration software. But when implemented new questions have to be answered and positions taken, as it raises the question of who has control on publicly available content. These questions go beyond the realm of usual novel technology implementation. Such questions could be, Do I moderate user input? Do I respond to criticism, do I moderate it, do I delete it? Do  I manage collaboration? What’s constructive criticism, what’s offensive content? Do I edit false user generated content? Do I respond to it? These are business decisions that have ethical ramifications, that should be clearly stated and enforced in a set of company policies for secure collaboration. If you’re asking yourself these questions we suggest reading and following Atlassian’s Sarah Maddox blog ( http://twitter.com/sarahmaddoxon Twitter) who’s been working and writing extensively on the subject.

Last but not least, on documentation review. Our belief here is that structured collaboration is the best collaborative solution to improve performance. We designed a structured group collaboration workflow where documentation stakeholders are assigned roles (reviewer, writer, manager, administrator) with specific rights and duties. We worked on this workflow with technical documentation professionals for more than a year to find the sweet spot between directivity and openness. Directivity so companies achieve optimal performance (time, quality, money) in the specific process of  documentation review, openness so each company can map its way of doing documentation review business to our workflow.

What’s your approach to collaboration in the different steps of technical documentation production and maintenance? What’s your take on open collaboration vs. structured collaboration?