Collaboration happens when multiple people work simultaneously towards a common goal. Collaboration software are tools which try to make working together easier and more productive.

There are hundreds of methodologies and approaches out there to collaboration. We want to bring the focus on one particular dimension: open vs. structured collaboration.

These are two different schools of thought.

The paramount of open collaboration is the well-known Wiki. A wiki allows anyone looking at content to comment and edit. Wikis make for a pretty ideal democracy in that people have pretty much the same rights towards content, at least the right to comment and edit. The underlying principle here is that if readers can contribute by acting directly on content then the quality of the content will quickly and incrementally improve and always be up-to-date. Its power resides in the cumulative brainpower of the crowd, its vulnerability in its openness. Wikipedia.org became in a few years the first online destination for reference knowledge, yet the authority of its content is by construction always questionable.

The idea of structured collaboration is to map an actual workflow (i.e. a set of rules) to the collaboration software. Users are assigned roles which give them permissions to do things the same way they would offline, or without the software. The underlying principle is that the software is a guide that lets you do exactly what you have to so you play your part in the well-oiled collaboration process. Structured collaboration works only if the underlying workflow is adapted to the task at hand. Therefore, structured collaboration solutions are usually specific to a task (like LiveTechDocs is for documentation review), or adaptable (enterprise resource planning software like SAP could be extrapolated as structure collaboration software for the whole company), or correspond to general needs (like Producteev is for task management).

The key here is to understand that if collaboration is a very general concept, choosing a collaboration software has to be very specific to the common goal assigned to the team. Better performance can be reached for some objectives through open collaboration (for instance tasks requiring significant creativity, fact-checking, moderation), while in other situations teams will perform best with specific and structured collaboration software (for instance tasks involving streamlined processes, time constraints, systematic involvement of team members, or tasks requiring authority, validation, accountability).

Even if you are opting for the benefits of open collaboration, choosing the right wiki has to be done in consideration of all aspects of the project and objectives. If you are going the wiki route, take a look at this map (Wiki Choice Wizard included) so you won’t get lost in wiki-land.

Now, let’s narrow this down to technical documentation, shall we. 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 collaboration solution.

On getting user feedback, Wikis are definitely a seducing approach, 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? 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. If you’re asking yourself these questions we suggest reading and following Atlassian’s Sarah Maddox blog (@sarahmaddox on 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 solution to improve performance. We designed a structured 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 vs. structured collaboration?