The enormous improvements in quality and productivity that have occurred in industry over the last several decades can, in large part, be attributed to a focus on improving first-run quality. In traditional production line environments, the golden rule was never to stop the production line. Any faults that might occur or be noticed while the product was on the production line were to be allowed to pass on, to be found and fixed in post production testing. Come hell or high water, though, the line must never stop.
Toyota turned this thinking on its head. Workers are encouraged to stop the production line whenever a problem occurred. No flaw is allowed to proceed through the production process. And when a flaw is discovered, and the line is stopped, they don’t merely fix the flaw, they do a root cause analysis to discover why the flaw occurred. Was it because of a design flaw, a parts problem, a flaw in the design of the production line? Did it result from an incorrect compensation scheme for buyers in the parts department, resulting in their buying inferior components? However far back the problem originated, it was found and fixed.
The result of this approach is consistently better first run quality, little or no need for post-production testing, and significantly decreased production costs. Improving first-run quality pays off big. (And once the system is working, the production line rarely stops.)In the software development world, the Agile development process similarly aims at improving first-run quality. Practices such as test-driven development of software, where you write the tests for a feature before you implement the feature, and pair-programming, where you have two pairs of eyes on the code as it is written, and two heads working out the design and looking for flaws, serve to significantly reduce the number of bugs in the first version of the software.
However, improving first run quality is not something you hear much about in content creation. Indeed, it is almost axiomatic in content creation that quality is the product of revision, and the more revision the better. As Craig Fehrman writes in the Boston Globe:
Perhaps the only belief that today’s writers share is that to produce good writing, you have to revise.
This cult of revision, however, is of recent origin. Fehrman, summarizing “The Work of Revision,” by Hannah Sullivan, an English professor at Oxford University, writes:
In the age of Shakespeare and Milton, paper was an expensive luxury; blotting out a few lines was one thing, but producing draft after draft would have been quite another. Writers didn’t get to revise during the publishing process, either. Printing was slow and messy, and in the rare case a writer got to see a proof of his work—that is, a printed sample of the text, laid out like a book—he had to travel in person to a publishing center like London.
Revision became part of literary culture with the typewriter and with the rise of modernism in literature, with its emphasis on paring back expression to the minimum. It is also, Sullivan suggests, a product of the writing instruction industry. Fehrman quotes Sullivan:
Writers need to look more like professors and to discuss their laborious processes. ‘We can’t teach you how to write, but we can teach you how to revise.’ And it’s a big business.
This same notion of the beneficial effects of revision is expressed in DITA and The Return of the Editorial Process, where Keith Schengili-Roberts argues that one of the benefits of content reuse is that when content gets reused, it gets looked at again by fresh eyes and can be edited and improved.
I have noticed over the years that one of the other inadvertent bonuses of this approach is that topics that are looked at most – when being evaluated for reuse – become “edited topics” and are improved in the process of reuse. In DITA environments, I am seeing the return of the editorial process as technical writers review and inevitably revise content written by their peers.
The problem with this is that every book and article I have read on the benefits of reuse, and on the ROI of reuse, assumes that a topic is reused clean. If a topic is reused three times, that is supposed to reduce the writing cost 3 times, and the translation cost 3 times. But if the topic is being revised each time it is reused, then it needs to be translated again each time it is revised, and the cost of revising and retranslating has to be figured into the ROI equation. The cost of revising and re-translating may well be less than the cost of separately writing and translating the content from scratch three times, but the savings are considerably less than if the content were reused without revision.
Rather than welcoming the chance to revise the content, therefore, should we not rather be asking why the content was created imperfectly in the first place, and why is was still in need of revision when it came time to reuse it? Perhaps the cult of revision blinds us from asking the same question that every other process has learned to ask: why was the part defective, and how do we get to the root cause of the defect and make sure it does not happen again?
Relying on revision to produce content quality is a serious problem in a marketplace in which product cycles continue to shrink, and in which customers increasingly expect content to be instantly available and constantly up to date. There is simply no time for a revision cycle in modern technical communication.
Many of us, of course, are simply living without the revision cycle, and sometimes complaining about the lack of time to do revision. But I think we have to get past the idea that revision is the only way to produce quality content, and instead look on the need for revision as the sign of a flawed writing process. Since we are never going to have the time for revision restored to our schedules, it is time to start doing the root cause analysis on why we are producing flawed content in the first place, and looking for ways that we can remediate our content development processes to improve first run quality.
I’ll have some suggestions on way to approach this in future posts. If you are interested in the subject, you may also be interested in my upcoming talk at LavaCon 2013 entitled More Content in Less Time, which looks at the application of Lean and Agile techniques to the production of content. If you want to chat about how you can apply these methods in your organization, feel free to contact me.