Is Collaborative Authoring Over-Hyped?

by Tom Johnson on Jun 12, 2012
categories: technical-writing • wikis • writing

If there's one business buzzword that you hear all over the place, "collaboration" must rank in the top 10. When it comes to technical writing, if we open our arms to collaboration, giving a warm embrace to "collaborative authoring" is only one more little step. It feels so tolerant and embracing to be collaborative. It fits in with Web 2.0 and the trend toward interactivity. In reality, collaborative authoring is little more than a euphemism for the idea that "anyone can write."

Last week I had a pivotal conversation with my colleagues about the topic of collaborative authoring. I was trying to remember what initially pointed me in the direction of wikis (the consummate collaborative authoring platform) in the first place. About three years ago, I was working on a project when another department asked for the source files, essentially cutting me out of the authoring process because InDesign offered no way to collaborate. I wrote a post titled The Case of the Stolen Documentation telling this story.

Each of my colleagues shared their own experiences with customers desiring editorial control over the documentation. (By "customers" I'm referring to business departments that sponsor IT projects, not end-users.) One customer group went so far as to buy their own copy of Flare to maintain and update the help. It was a nice idea, but the results were less than impressive (not because of Flare, but because the customer group using it didn't include professional writers).

Another customer leveraged a small army of subject matter experts (SMEs) to help write content, but the results were often unusable. They produced a lot of poorly written text that, in the end, turned out not to be that helpful for people learning the software.

Another colleague crowdsourced the documentation among a group of volunteers (at my recommendation), but the management overhead nearly paralleled the saved writing time.

For my experience, I noted that customers often make a big deal about having everyone on their team be able to update the content, but then no one makes any updates at all, beyond a few words here and there. Most people want the possibility of control without any of the responsibility to do the work.

All of us agreed, somewhat reluctantly, that none of us has had much success with collaborative authoring.

If we were collaborating with professional writers, I'm sure the results would be different. But most of the time, the collaborators were customers who wanted to own and maintain the content. Shared control of content sounds like a good plan in theory until the reality sets in: customers don't maintain the content much at all, the edits they make are sloppy and unorganized, the product's quality takes a turn for the worse.

Many other professionals in an IT organization never encounter this request for collaboration. When a designer creates an illustration, does the customer ask for the source files so the customer can make needed updates? Does the customer ask developers for the source code so the customer can make needed updates? Does the customer ask the application systems engineer for the password to the server so that the customer can optimize it if need be?

No, but somehow writing is different, because didn't you know, anyone can write? Yes, just give the customer the control he or she wants. Don't be such a writing snob. Let's all work on this together.

Under the allure of collaborative authoring, we bend over backwards facilitating the sharing of content through wikis and other collaborative solutions, only to realize time and again that good writing skills are a rare possession.

Yes, even though most people feel they can write well, and therefore ask for shared ownership of content, their writing skills don't often lead to creating good help documentation. Writing is a spectrum skill, so at the lowest level, yes, just about anyone can write a sentence or two, as with email and Twitter. My five-year-old can write her name, in fact. But as soon as you climb up the scale of difficulty, writing requires more and more advanced skills, to the point that writing quality content that solves customer pain points in relevant, easy-to-understand ways is a result only professional writers can achieve.

For more on the topic of "anyone can write" (or writing as a commodity) see my previous post, What Does It Mean to Know How to Write, and also Mark Baker's philosophical reflections, It's Time for a New Doctrine of Technical Communications and Scott Abel and Jack Molisani's Tech Comm 2.0: Reinventing Our Relevance in the 2000s.

Let's return to the question: What's the answer to the customer who asserts that he or she wants to own and maintain the content once we draft it? Do we deliver it up in a format he or she can update, like Microsoft Word? Do we get the customers licenses to help authoring tool clients that allow them to edit in the browser (such as with Author-it Live), or on their own machine? Do we resort to wikis and other online solutions that allow our customers to log in and change/update/revamp/ruin the content? (See my essay My Journey to and From Wikis for my experience following that route.)

Although all of us admitted that our efforts toward collaborative authoring weren't that successful, we also confessed that nearly every customer wanted to own the content -- the source files -- once we completed our work so they could update the content. What do you do with these requests? Can you really say no to the customer? Can you decline the project sponsor?

My colleague noted that if we insist on owning the content, we have to own it throughout the lifecycle of the content, which means ensuring we stay updated about each and every update as long as the product is alive. If we host the content on our server, we should regularly review the content against updates to the applications and make sure we're keeping the content up to date -- long after our involvement with the project has ended.

And if we own the content, why not keep our content in whatever format we prefer (DITA or Flare or some fancy custom XML schema we've developed) and deliver a non-editable help output, such as a webhelp or PDF. If people want updates, let them send us a request or log a bug in JIRA.

Is that too harsh? Perhaps. But I've been playing the collaborative authoring role long enough to grow tired of it.

I'm curious to hear how you have handled requests for shared ownership of content, or how you approach collaborative authoring with non-writers. Surely for those teams writing in DITA, using Flare, Robohelp, or other HATs, collaborative authoring isn't something that anyone can just jump in and do, as with a wiki. For those using wikis, are the edits from customers frequent and regular, or are they sporadic and poor?