Drafting documents with others is one of the most important but stressful parts of many professionals’ roles. At a minimum any organisation with a quality management system will have a review process, where someone else will add comments or suggestions to drafts before approval. There are many scenarios where multiple people need to contribute to the same document because they have different fields of expertise or they have different viewpoints that need to be expressed.
Historically document collaboration meant circulating hard copies or disks and receiving comments or markups which someone would need to painstakingly combine. In recent years, many people have moved their document drafting to online methods. These methods allow for quicker interaction between collaborators, whether that is using email, document management tools, or real-time tools.
Why different types of collaboration are necessary
Important documents are often drafted by teams of people who might have competing objectives for the document. In this instance, it can be beneficial to ensure that there is a clear process for controlling who can draft edits, create safeguards to make sure unwanted errors aren’t introduced, and manage traceability of how decisions are made.
Drafting an important document with multiple stakeholders is a consensus-building process. It’s more than just putting the right words in the right order; it requires expectation management, negotiation skills, and good communication.
We created Barbal because we saw that people working on important documents don’t have the tools that let them collaborate efficiently. Different document editors promote different behaviours between collaborators and we wanted to make something that allows experts to do their jobs and negotiate faster.
A key aspect here is trust. Technical trust means can you trust someone not to make a mistake which can undermine the credibility of the document, this could be competence in drafting or expertise in the field. Even administrative tasks need to be undertaken by someone competent in the field, lest a seemingly minor error causes a major problem.
Another aspect of trust is the alignment of interests between the different parties to the collaboration.
The concept of the “master document” is how trust is handled in collaboration. Who can edit the master document? Who is responsible for making sure the document is coherent overall? Who can approve changes?
In this article, we explore three different collaboration options available:
Linear collaboration involves a single master version of a document that is passed between stakeholders, usually via email, file sharers or a more sophisticated document management solution that allows check in/checkout . This creates a game of email tennis where it’s often unclear who’s holding the ball. A collaborator makes an edit and forwards the document as a file in an email, and another collaborator either revises or accepts the changes and emails the document back or along the chain.
- Personal documents which won’t be shared with others
- Letters and correspondence
- Essays and dissertations
- Documents where people different people work on distinct sections that can be stored as individual files
- When only one person will be working on a draft at one time
- It is easy for changes to the document to get lost in translation due to a lack of version control and issues with comment tagging
- High risk of human error when making edits
- Security risk, as everyone who is sent the document has the master version controlling who has access can be problematic
- Communication, as there is no real-time communication method with linear collaboration, those who should be involved in a direct line of communication can often get isolated. This can lead to edits made to the document getting overlooked
For large teams co-authoring the same document, linear collaboration is the opposite of a streamlined process. Collaborators spend more time sending emails, chasing feedback and searching for the most recent version of the document than actually working on the document. This leads to quality issues, delays and team member frustration. The entire process is fraught with distractions and complications which can make it stressful, turning experts into administrators, constraining their ability to do the best job they can.
Real time collaboration
Real time collaboration involves multiple users producing work on the same single document at the same time. Co-authors can make comments, suggest edits and revise documentation in a web application or collaborative software simultaneously in real time.
- Small teams working on informal documents
- When there is small number of authors drafting in a linear manner
- When there is a high level of trust between all collaborators
- Idea generation and rapid iteration
- Documents that are drafted or reviewed during a meeting or workshop
Not suitable for
- Teams with more than five members collaborating on one document
- Complex documents
- Asynchronous collaboration
- When privacy is needed
- Working with third parties
Real-time collaboration can be great for creative teams that need to collaborate synchronously. For example, when teams are brainstorming ideas and need complete visibility of each other’s work. However, when more than five people are working on the same document the process becomes painful as there is very little control. Co-authors can easily step on each other’s toes whilst making changes to work. This becomes particularly problematic when teams are working on complex documents or working with clients. With real-time collaboration, privacy and control are sacrificed, leading to a disorganised workflow.
Concurrent collaboration (Barbal’s Solution)
Concurrent collaboration involves co-authors working on their own copies of the same document, where the editor automatically merges and disseminates updates between the collaborators. Unlike real time collaboration, co-authors have full control over their workflow; granting collaborators the ability to focus on their own work, draft in private and share their edits when they are ready. Everyone has access to the content relevant to them. Contributions are systematically reviewed before they are merged into the master document.
- Collaboration between distributed authoring and editing teams
- Engagement with stakeholders throughout development
- Maintaining a full audit trail of dialogue, decisions and justifications
- Collaborating with clients or other parties
- Progress monitoring and reporting
- Accurate version control
- Shared ownership of work
- Instant communication between stakeholders
Not suitable for
- Synchronous collaboration
- Intense creative collaboration
Concurrent collaboration allows for decentralised(?)control over different sections of a document. Allowing stakeholders to concentrate on specific sections of a document without interfering directly with the master document. When authors are working on complex documents asynchronously, other co-authors having instant visibility can add unnecessary pressure. Concurrent collaboration supports individual team members working efficiently with each other without explicitly exposing their thought processes.
Although both linear collaboration and real-time collaboration certainly have their respective advantages, when teams of over 5 members work on the same project their pitfalls can not be ignored, when compared to concurrent collaboration. When teams collaborate in real time the workflow can become abrupt and chaotic. When teams use linear collaboration the process becomes stagnant and unnecessarily time-consuming.
Barbal was created to bridge the gap between linear and real time collaboration by adopting a concurrent methodology. Incorporating a catalogue of all contract drafts, version control and comment flagging directly into the user interface. The software eliminates any security or privacy risks keeping a full audit trail of contributions and changes by all parties in one place without the need for any exterior tools. Barbal frees teams from needless admin and waste, ensuring business-critical documents get signed-off faster.