Document Collaboration - A New Approach?
I was reading one of Craig Randall's recent posts about creating new market opportunities and it got me thinking about how we collaborate around documents today and whether it really is optimal.
Back in the day when I was a UNIX programmer I worked with someone whose theory was that some developers were really good at writing the first 80% of the code and some were really good at the last 20%. We all took this to mean that he was just not a very good programmer...but maybe he was on to something.
Currently, when we collaborate on documents we tend to do the following:
- Each person completely finishes a section - they write chapters 4-6 of the technical manual while someone else writes Chapters 1-3 and 7-10. The pieces are then combined in to the finished document.
- You write a document and then route it for comments, incorporate the comments and then rinse and repeat until the document is complete.
- One person or team writes the entire document and then it is routed off for approval, processing, multi-channel publishing, printing, etc.
The point is that we don't collaborate until we have finished something to the best of our ability. We tend not to send something half finished off for someone else to finish - or even finesse.
So, back to Carl's 80/20 model for developing...how might it apply to writing documents? I am writing a book; I spend a lot of time reading, researching, formulating ideas and then I write them down very quickly - I "brain dump" to paper all of the intellectual capital that spews from my brain. I then probably spend 5x the time building a logical framework around the thoughts, making them flow, cross referencing & validating them, etc. This is a huge task but not something an editor could do. However, if I could afford a team to assist me I could have a process like this:
- I brain dump my ideas to the page.
- A subject-matter-savvy person then reads, reviews and validates my thoughts. They then re-organize my writings to give them flow and logic.
- I review that the concepts have not been changed
- An editor then edits the document and formats it to suit.
- I review and approve.
- The publisher prints the books
Is this really that different to how we collaborate today? As an author it is because there are certain tasks that only I can do but there are other tasks that I could outsource.
Having finished this fairly uninteresting rant I realize that a ghost writer effectively does this today...maybe what I am looking for is a technology that supports that process. I have tried software that helps to gather research for book writing but they are a far cry from mature enough to support this type of process.
So, Craig...if I write the first 80% of a solution, will you finish it for me?


Right... so maybe you aren't looking for a technology that helps you do it, rather, you're looking for a technology to do it for you... or more succinctly, you're lazy. That's okay, don't panic, humanity is inherently lazy and I like the way you've spun "lazy" into a collaboration message with the whole "some people are good at some things and others, other things" line - 80/20... hilarious, very creative, you show promise as a marketer. And really, I do suppose the primary purpose of a collaboration solution is to divvy-up workloads, or diminish one's own workload, or, do less work and be lazy. As an engineer (and not a marketer... although I do believe you show promise) I expect you will (in short order) propose the development of a Webpart for "Lazy" that can be seamlessly utilized in the collaboration workflow of SharePoint. By the way, which reference architecture would this fit into?
Reply to this
We've been well schooled in the "create ->review -> edit -> publish" paradigm. In fact, much of the way we work and our current professional and personal reward structure is based on this paradigm. I'm an author, I have deadlines, I'm responsible for this content, etc.
Wikis open up another paradigm, where the group is responsible for the content. What we now need are the personal and professional reward structures and management frameworks that value wiki style collaboration. These kinds of deep changes are hard to make.
Reply to this
Geoff,
I could not agree more. I think that one point that is often missed by companies is that by encouraging employees to get involved in publics, wiki-style collaboration they are actually showing thought leadership. I form a lot of opinions about companies simply based on how key employees project themselves in the 'Blogosphere'. That’s marketing that you could not buy…
Andrew
Reply to this