Wikipedia defines single sourcing as “a content management method which allows the same source content to be used across different forms of media and more than one time. The labor-intensive and expensive work of editing need only be carried out once, on only one document. This reduces the potential for error, as corrections are only made one time in the source document.” A decent, I think, explanation of what this mysterious approach to documentation is all about.
More simply, single sourcing is a way to store documentation content such that all the different outputs – user guides, online help, requirements, etc. – are derived from the same content.
For example, a company develops a web-based application targeted at the company’s US merchants. Initially, the product manager believes she only needs a user guide to post on the website in PDF format (a dubious decision, but more on that later) so instructs her technical writer to create the documentation in Word so she “can maintain it” herself.
The product is released. Yay! Now, the users request online help because they hate having to open up PDF files to find an answer. The product manager asks her technical writer if she can “convert” the Word file into an online help system. The technical writer imports the file into the tool of her choice (Flare, RoboHelp, etc.) and generates online help. Now there are two separate “projects” for the technical writer to maintain (the product manager has agreed she’s too busy managing her product to write documentation).
Then resellers ask if they can get a white-label version of the documentation so they can resell the product to their customers without their customers knowing they didn’t actually write the application. So the product manager asks the technical writer to take the existing documentation and create a white-label user guide and online help. The technical writer now has four projects to maintain.
You get the drift here. As the developers begin enhancing the product by adding new features, each change in the application requires a change in four separate documentation projects, four separate edits, four separate reviews, and so on. And that’s only if there are four iterations of the same content. We’ve had real-life instances where our client required help desk content in a specialized format of the same content, Canadian content (with minor differences in content) such that we were actually maintaining close to 12 separate documentation projects for content that was probably 80% the same.
Talk about inefficiency and expense!
Or let’s look at the Request For Proposal (RFP) problem. Most companies have to respond to RFPs regularly where 75% of the content they provide is almost exactly the same – boilerplate content about the company, the management, the approach to the industry, the products, support, etc. Many companies still use Word to respond to these RFPs. The problem, as they never cease to tell us, is that while the questions they are asked to answer are similar, they are never asked in exactly the same order and the questions are never exactly the same. One RFP might ask about the management structure in the beginning of the RFP; another at the end. One RFP might simply ask for the management structure of the proposing company; another might want to know how the experience of the management team from the proposing company makes the company a better solution for the challenges articulated in the RFP.
Simply copying an old RFP response and editing it is certainly one way (one inefficient way) to go about the problem, but the time wasted and opportunities for error that approach creates make it a very undesirable solution. Especially when the same issues arise the next time the company has to respond to another RFP.
Fortunately, there are tools available to make documentation management simpler and more efficient. When the technical writer can set up the project in these tools – and not have to convert existing documents after the fact – the cost is negligible. Conversion is labor-intensive and, by extension, more expensive. However, as we’ve learned from working with some of our clients, most companies can recoup the cost of converting documents into single source tools in two or three iterations, which for many of the companies we work for, means in a little over a year. And from that point on, it’s “all gravy.”