Writers have all along been collaborating to write manuals using various tools. Some have used Word to write and have used folder structures and file naming to store documents. They have defined a basic process to collaborate. Many have used server versions of FrameMaker to work on the same book. Content Management Systems (VSS, Perforce, etc) have been really useful too. Help authors have created topics in Robohelp and efficiently worked and on single help file outputs.

Writers have co-existed and collaborated on the same guide or at the project level. Writers have reviewed work of peers. While one writes another has taken care of graphics. Of late writers have used WIKIS in a big way.

Competitive and collaborative writing is the future of information. A company could ask two vendors to work on the same piece of software and provide content. Then they could select the one that suits their needs. Projects would ask two writers to work on the same chapter. While this sounds like repetition, there is a clear purpose.
The advantages are:

– Both writers gain knowledge of entire product
– If one writer is not around, the other can still continue
– Content is analysed thoroughly
– At the end of each phase of the DDLC (document development lifecycle) the writers collaborate to share notes and enhance the content. This irons out any major blocks.

However, this requires double the investment. A style guide and an Editor are a must. Writers would need to vibe and work towards a common goal. Both writers should be of equal skill and bring two perspectives to work.

This might sound crazy but I have seen this work. In 2003 my manager used this trick to chuck out a writer who had used various tricks to get the job. The notorious writer gave reasons while the manager provided a user guide to the client! Last year I worked with a writer from the UK to deliver a document faster. We learnt a lot from our work each week and it helped solve writers block often caused by not understanding something well enough. We kept the technical team in place. Of course we had some clashes which we dealt with through our third eye – the editor.

This model is useful when the focus is on the quality and importance of technical documentation.