Collaborative writing: a skill or an art form?
Sometimes it seems that all communication today is in sound-bites, 140 character tweets or blog posts. Anything beyond 500 words seems to be in the exclusive domain of poets, novelists and other professional writers.
Not so for the Management Consultant. Creating a proposal for a client or drafting a report at the end of a project is a regular exercise. The consultant-tool-of-choice seems to be PowerPoint and a picture says more than a thousand words. But to convey the details and nuances of a message will quite often require a significant amount of text. What differentiates the consultancy profession from most other writing trades: consultants usually work together when writing. Many consider writing an art-form but collaborative writing requires a common set of tools and a systematic approach.
Overall there are two specific requirements to the whole process: efficiency and consistency. Both of those benefit by a structured approach that has similarities with traditional software development. Development consists of several stages: Analysis, Design, Implementation, Testing, Maintenance. Assuming that the delivery of a document is a one time event, collaborative writing also includes four stages:
- Analysis – capture the relevant input
- Design – create the storyline
- Write – the actual production of the document
- Review – against the earlier deliverables
Consistency requires that any stage has been concluded in sufficient level of detail before multiple contributors start elaborating in the next stage.
Short iterations
Efficiency dictates that only short iterations are allowed. New insights during the creation of the storyline (Design) may be input to refine the outcome of the Analysis. But once the activities move towards Writing, the Analysis should be fixed. Reviewing is done against the deliverables of the Design stage. This of course will only work if the design deliverables are fixed when the Reviewing starts. A version of Boehm’s Law applies here as well. the later a change(/error) is initiated(/found), the higher the associated effort to process(/correct) it.
During the Analysis the components of the main story are created; key messages, main conclusions, repeating themes and which items from the raw data will be used as input for the storyline, all of these are decided before the Design starts. In parallel the practical stuff is addressed: which template will be used, what writing style will be applied (formal or more casual) and which wording or key-phrases will be used to address certain topics or subjects? Typically this is made explicit in deliverables which are used for subsequent stages. With all basic choices settled, the Design phase is used to elaborate the general storyline.
Core team
A small core team will develop the storyline in sufficient detail for the writers to contribute in the next stage. The core team establishes the number of chapters, a table of contents for each and the storyline per chapter. This approach leaves limited room for ambiguity from the writers as the core team has already taken all the decisions. Therefore new writers get quickly introduced into the context and the chosen direction based on the deliverables from Analysis and Design stage. This approach also has impact in the Review stage: there is a great level of detail in various deliverables as context for the reviewers to assess the quality of the final deliverables.
Consistency is a given in the above where a less structured approach holds the risk that individual writers create a divers and inconsistent end-product that requires significant effort to align afterwards during the review cycle. The main threats for efficiency are the iterations; it is important to really finish a stage before moving on to the next.
(More on this topic in Better is the enemy of good enough…)