A couple of weeks ago, in a post titled Improving First Run Quality, I cause a kerfuffle, and some questioning of my sanity, by suggesting that rather then celebrating revision as an essential part of the writing process, we should regard it as a sign that the writing process is flawed.
Today I wish to expand on this idea that we should be regarding revision as a bad thing. One of the key principles of lean thinking, which takes it inspiration from the Toyota production system, is the reduction of waste in the production process. Waste is anything that does not add value to the product. Rework is waste. If work is done, and then has to be done again, that is wasteful. Revision is rework, therefore revision is waste.
Technically, it is the original work that had to be redone that is the waste. The rework sets things right, and therefore does add value. But the original defective work was waste and did not add value. Rework, then, is the sign that waste is occurring earlier in the production process.
When you find something broken that needs to be fixed, of course you have to fix it. If you find content that needs to be revised, of course you need to revise it. Revising isn’t bad, but it is a sign that something bad has happened. It is a red flag that wasteful work occurred earlier in the process.
So, when we find ourselves revising, we should be asking, why was this content not written correctly in the first place? There could be many reasons. Lets examine a few possibilities:
- The product specification changed after the content was written.
- The writer misunderstood the subject matter when they originally wrote the content.
- The content was written by a subject matter expert who did not know what needed to be written or did not write it well.
All these things happen regularly in tech comm. We respond by revising. We accept the fact of the wasteful first effort and move one. Should we be accepting it, or should be be asking why the wasteful work occurred in the first place, and thinking about how we could avoid that waste in future?
In the first case, the product specification changed after the content was written, there are several questions we could ask, like:
- Was the content written sooner that it needed to be? Could it have waited until the specification was more stable?
- Could the specification process itself be changed so that it creates less rework in both development and tech comm?
- If we had a more systematic approach to documenting these things, might we have caught the problem in the specification earlier?
In the second case, we could ask things like:
- Is the correct writer being assigned to the task?
- Are we using the right criteria when hiring writers?
- Are we paying writers too little, meaning that writers who understand this technology are not willing to come work for us.
- Are we not providing writers with the equipment and access they need to learn the technology?
- Are developers unwilling or unable to help writers when they need it.
- Does the writer know the right questions to ask? Do they know what users typically need to know about this subject? And if not, can we help them by providing a structured writing environment that prompts them to provide the required information.
In the third case, we could ask things like:
- Are we assigning the writing task to the wrong employee?
- Could we improve the content the SME creates by giving them a form to fill in?
- Could we extract the information we need from the code itself rather than asking the SME to write it down?
Another important thing to ask when we find ourselves revising is, could this have been caught earlier? It is one thing to revise in response to a change in the specification at the time the change occurs, and quite another to have to revise weeks or months later, or after the product is in the field and a customer is losing productivity because of the incorrect information.
Content in need of revision is content that contains a defect. It has been shown in multiple studies in multiple fields that the expense of fixing a defect grows exponentially the longer the defect goes undetected. Detecting and fixing a defect immediately is usually cheap. Finding it and fixing it later could cost thousands or even millions. One of the most important questions you should ask when you have to revise is, how long ago was this defect introduced into the content, and why didn’t we catch it sooner.
A revision, therefore, may be a sign that your quality control processes are poor. One of the biggest problems in quality control processes is often that they simply occur too late in the process. If you write an entire book before you send it for review, then you have a very long-cycle quality control process, meaning defects are not detected promptly, and your quality control will be poor for several reasons:
- The writer who created the content defect because the misunderstood the product will have continued with that misunderstanding as the wrote other content, meaning it too has to be revised. If their content is being reuse, the defective content may be in several places. If test uses documentation to create tests, the tests may be incorrect. If training uses it, the training could be bad. If sales uses it, false customer expectations could have been created and possibly even contracts rendered invalid.
- The longer between the time the engineer developed the function and the time they review the doc, the less clear their memory will be, and the more likely they will miss the defect, which will only further increase the time before it is discovered and the cost of correcting it.
- The more stuff you give the engineer to read at one, the more rushed they will be and the worse job they will do, with the same consequences.
The agile development approach is sometimes criticized for creating rework by not rigorously defining the specification of a product up front. But what agile is really designed to do is to decrease the amount of time it takes to detect errors in the specification itself, and thus reduce the cost of specification errors. An error in the specification in a waterfall development process may not be detected until months or even years later, after the project has been finally delivered to the customer, and the cost of fixing it at that point can be astronomical.
Of course, the iterative development that agile practices, can result in rework, and rework is waste. But there are times where some waste is inevitable. Sometimes you need a prototype to test the specification, and if the prototype reveals a defect in the specification, then the prototype will have to be reworked. That is still waste, but it the lessor of the two evils compared to not testing the specification until final delivery. Similarly, there can be revision of content that is unavoidable because it results from a need to test the specification, or for some other unavoidable reason.
Even so, it is still waste. And a lean process is never satisfied. It may accept that it is useful to trade waste in one area to avoid waste in another area, but it still seeks for perfection. It still bids us to ask, can we further reduce waste here without increasing waste over there?
This brings us to another property of a lean system: evenness. One of the keys to lean thinking is to look at the overall production flow and strive for evenness through the whole production process. Sometimes optimizing one part of the process introduces unevenness in the other parts of the process, creating more waste than it removes. The point, then, is not to optimize the writing process by removing all occasions where revision might occur, even if it disrupts the rest of the development process. The point is to recognize that a revision is always a sign of a defect introduced earlier in the process, and that the source of that defect should always be investigated.
We may never remove all revision from the writing process, but we should always see it as a sign that our process can be further improved.
I’ll talk more about this in my LavaCon 2013 talk 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.