More Content in Less Time—Applying the Lessons of Lean Thinking to Technical Communication

Home/Publications/Best Practices Newsletter/2005 – Best Practices Newsletter/More Content in Less Time—Applying the Lessons of Lean Thinking to Technical Communication

CIDM

February 2005


More Content in Less Time—Applying the Lessons of Lean Thinking to Technical Communication


CIDMIconNewsletter Mark Baker, Analecta Communications, Inc.

Content developers today face many challenges, but none is more urgent than this: how to create more content in less time. Content developers are not alone in this plight. Manufacturing workers, industrial designers, and software developers have all been forced to increase both their quality and productivity in dramatic ways. Workers in these fields have made significant strides thanks to some new ideas about manufacturing and design. Content developers can learn from the progress that has been made in these fields.

How does Toyota bring a new vehicle to market in one year when it takes most of their competitors two to three years? The answer is the Toyota Production System (TPS), a comprehensive approach to product design and manufacturing that has allowed Toyota to produce vehicles that are more reliable and higher quality, sell them at a competitive price, pay higher wages, and make greater profits than their American counterparts.

The TPS has been the object of much study and imitation. “Lean thinking” is a set of principles developed by James P. Womack and Daniel T. Jones based on their study of the TPS and the companies that have followed Toyota’s lead. The key to lean thinking is the elimination of waste from production and design processes. To discover and eliminate waste, lean thinking offers five basic principles:

  • Specify value: waste is any process that does not add value to the customer. In order to identify waste, you must first specify what is of value.
  • Identify the value stream: trace how value is added to a product at each stage of the productive process. Waste is defined as all the steps in the process that do not add value.
  • Flow: the productive process should flow without interruption, without waiting, and without unnecessary movement.
  • Pull: nothing should be produced until it is needed by the next step in the process.
  • Perfection: an organization must be committed to building and maintaining a culture in which every employee is dedicated to reducing waste and improving quality.

Traditional Batch and Queue Manufacturing

In manufacturing, the dominant idea for many years was that big, fast, highly automated machines were the most efficient way to produce parts, and that, to be efficient, these machines had to be kept running at high speed. This practice, however, required a large stock of raw material to be maintained to feed into the machine and a large inventory of finished goods to be maintained after manufacturing until they were needed. This is called the batch and queue method of manufacturing.

Large inventories on either side of the machine are wasteful. A large amount of capital is permanently tied up in maintaining this inventory. Defects in the manufactured good are often not detected until long after they are manufactured, and large quantities of similarly defective products can be manufactured before the defect is detected. Changes in business needs can render large quantities of inventory obsolete at any time. Finally, because parts are manufactured in large batches, if you run out of inventory for a part, new production of that part may not be scheduled for weeks. A new customer order might be delayed until the necessary parts became available in the production cycle. These delays produce waste in the form of lost sales or lost time in which sales revenues are not in the bank. To avoid the possibility of such interruptions of supply, downstream customers will often maintain their own parts inventory, once again tying up capital in wasteful stockpiles.

What Toyota demonstrated with the TPS, and what many other manufacturers have since realized, is that the cost of waste in this kind of system far outweighs the benefits of running the big machines full tilt. In a lean production environment, nothing is manufactured until it is needed. Parts are made in smaller batches and they are made only when they are needed by the next step in the manufacturing process. Often, smaller and simpler machines are used that are easier to change over from making one kind of part to making another. Even though these smaller and simpler machines may be less efficient on a per unit basis, they allow the factory to work with virtually no inventory and therefore none of the waste associated with the maintenance of that inventory. Defects are discovered immediately, so very few defective parts are produced. Nothing is made until it is needed, so inventory is never made obsolete. And the machines themselves are less expensive. Lean manufacturing environments produce higher quality products at lower prices and they deliver much faster and more consistently.

Lean Content Development

Since authors do not have access to big, high-speed machines that produce large volumes of content at high speed, it may be hard to see how the lessons of the TPS can be applied to content development. But lean thinking is not about transferring specific practices from one company to another or from one environment to another. Lean principles can be used to reduce waste in any process. Let’s look at one example.

One of the great, long-standing questions for technical writers is, “how do I get the developers to review my documents on time?” Many suggestions are offered, from the carrot (bring them muffins), to the stick (persuade management to put it into their performance reviews). But the real problem is not that the reviewers are unwilling to do the review and need to by bribed or bullied into doing it-the problem is that the review process does not flow. Writers typically spend months creating huge documents and then send them for review all at once, usually at the end of the project when everyone is most busy. Content moves through different stages of creation just as a physical product moves through different stages of production. If content is moved through that process in the form of complete documents, we find the equivalent of batch and queue manufacturing with the document representing the pile of inventory sitting between the writing process and the review process. To create flow in the content development process, therefore, you need to develop content in smaller batches and have that content reviewed incrementally over the course of the development process.

There are several benefits to incremental review.

Incremental review promotes learning
When Stilo added records to the OmniMark programming language, I was responsible for documenting the new feature. I formed a model of how records worked that was sophisticated, complex, made perfect sense, and seemed to be consistent with the software I was testing it with. It was also dead wrong. Fortunately, we were using an incremental review process, and the first item I sent for review showed my misunderstanding. Had I not had that review, I might have developed a complete set of content based on my misunderstanding. Fixing it would have been a huge effort that might have delayed the release of the product. Whether in manufacturing or content creation, one of the great benefits of flow is that it exposes defects early, reducing costs and improving quality.

Incremental review is more efficient
Being able to review a few topics each week is much less disruptive to a developer’s schedule than being asked to review an entire book at the very end of the development cycle. When I ran the documentation department at
OmniMark Technologies, we implemented a system in which each information component was printed and given to a developer for review as soon as it was completed. Several of the developers told me that they saved them to review on the bus on their way to and from work. Others would do them during breaks. We had prompt turn-around on our reviews with no disruption to the developers’ schedules. One of the key beliefs of the TPS is that you must avoid overburdening people. Incremental review avoids overburdening developers with last minute content to review and writers with last minute corrections to make, thereby reducing costs and improving quality.

Incremental review catches more errors
Incremental review catches more errors than full document review. There are several reasons for this. First, developers are not rushed by having a large volume of material to review close to the product deadline. Second, because developers are being asked to only review one piece of information at a time, they can focus specifically on that one piece of information. Most significant, however, if you can time the review of the information so that review occurs just as the developer has finished working on a particular feature, then you can catch the developer when the knowledge of that particular feature is still fresh in his or her mind.

Developers have to hold a large amount of detail in their heads during the design and implementation of individual product features. Not surprisingly, once work on a particular feature is over, those details are pushed aside to make room for the details on the next feature. Harmonizing the information development process with the product design and development process provides the opportunity to have developers review material while the details are fresh. This is how the principle of pull applies to content development. The implementation of a feature pulls the creation of the content that describes that feature. This method not only produces better reviews, it is also easier for the developer, who is not required to put aside the details of his current project to try to recall the details of an older project.

Incremental review improves completeness
When I have introduced incremental review into an organization, the fear most often expressed is that incremental review risks not finding omitted information. My experience has been exactly the opposite. Incremental review achieves a greater degree of completeness. This may seem paradoxical. Some people fear that if a reviewer does not see a whole document, he will not notice if something is missing. My consistent experience has been that when reviewers see a topic in isolation, they are actually more likely to think of related issues and to ask where they are documented. Confronted with an entire document in one sitting, developers often overlook large omissions. After all, it is a big job to review a lengthy manual all at once, and it is easy to fall into a rhythm of turning pages and not asking too many questions.

Incremental review builds awareness of the documentation process
One of the key concepts of flow is to make sure that everyone working on a production line can see the entire line and the products on that line throughout the process. This is impossible in a traditional factory where machines are often grouped in separate departments and where piles of inventory often block the line of sight. Flow makes the production process visible to everyone, enabling workers to spot problems as soon as they occur. It also enables workers to see and appreciate how their tasks affect the entire production line.

One of the biggest problems faced by technical writers is that they are often not informed of changes in design by the people who make those changes. The root cause of this problem is that the people making the design changes are often not aware that the content development process exists and they don’t know how it works or where content developers get their information. Document review at the end of the development cycle does nothing to enhance their awareness. A book lands on their desk out of nowhere. They do not gain any understanding of where content comes from or how it is created. The content creation process is invisible to them.

Incremental review makes the content development process visible. Developers who do incremental review of content become much more aware of the fact that there is a content development process going on in parallel with their development activities. Early and continuous review puts the information development process into the developer’s face. They know content development is going on. They know they have read an information component on a particular topic, and they often realize that the change they are making will affect that component-a component for which they have already taken responsibility by providing sign off.

The Big Picture

It is not possible in an article of this length to discuss all the ways in which lean thinking can find and eliminate waste in the content development process. Nor is lean thinking ultimately about a list of specific techniques. Every work situation is different, and what works in one place does not always work in another. The specific methods used in a particular lean organization should be viewed as examples of principles in action. To create a lean production process in your own department, you must learn and apply the principles to your own tasks, not blindly copy the practices of another organization.

I believe that moving to incremental review from monolithic document review is one of the best and easiest improvements that you can make in the content development process. As I pointed out in the sections above, it leads to reduced cost, better quality, and lower stress levels in a number of different ways. That said, incremental review is a specific application of the principle of flow. Like flow in manufacturing, it improves content development by removing inventory, revealing defects as soon as they occur, and making the production process more visible to all those involved. But in your organization, you may find that it is appropriate to apply the principle of flow in a different way. Or perhaps another starting point is more appropriate for you. For instance, if you are creating a large volume of content and are not sure if anyone ever reads it, then you need to start by specifying value and launching an initiative to determine what content your readers actually want.

Getting Started on Lean Thinking

How do you decide where you should start? Here are some simple rules to keep in mind:

  • Do not start by buying a content management system. Do not start by converting all your content to XML. A thorough assessment of the waste in your current process and the application of lean principles may lead you to the adoption of these technologies. Alternatively it may lead you in exactly the opposite direction.
  • Do start with value. If you are not sure what the value is in each and every piece of content you create, then there is no point in doing anything else until you have found out what users want. Production of things nobody wants is always 100 percent waste, no matter how efficiently you produce it.
  • Map your value stream and identify those activities that do not add value. Apply the principle of pull so that nothing is made until it is needed. Apply the principle of flow so that things are produced in a swift, transparent way that brings defects to light as soon as they happen.
  • Commit to perfection. Build a culture of lean thinking in your organization so that every employee is dedicated to eliminating waste and creating value. CIDMIconNewsletter

About the Author

February 05a4