Print/Download ArticleOutsourcing Product Support Manuals

Managing the Development Process

by Thomas P. Burke

This is the third and final article in the series Outsourcing Product Support Manuals: A Product Manager’s Perspective. The first two articles dealt with design issues such as deciding what to put into the manual and determining what delivery medium to use. This article focuses on controlling the development process to insure the desired outcome.

Every job needs a plan. In the case of a technical manual, the primary planning document is the outline, which should be the first deliverable developed by the writer once the design concept is firm. The outline should drive down to at least the second-order paragraph heading level, and should include a brief narrative description of the intended content for each heading. You should have the writers deliver a sample section early-on to make sure they are on the right track. Periodic in-process reviews thereafter can be a useful tool for keeping the project on track.

A milestone schedule is another important part of the planning process. The milestones in the tech manual schedule should be linked to equipment manufacturing milestones to make sure that the schedule is realistic, and is compatible with the production plan. The trick is to manage the development so that the manuals are ready by the time the first production model rolls off the assembly line.

It’s best to start the schedule at the day the manual is needed in its final form – printed copy, CD-ROM, etc – and work backwards from there. The major milestones in the process are:

  • Outline/Book Plan submittal
  • Sample section delivery
  • Draft manual submittal for desktop technical review*
  • Delivery of corrected draft for validation of procedures
  • Procedure validation
  • Final revisions and layout
  • Reproduction complete

* Within the development activity, there should be internal milestones that show the key activities and events for each chapter or section.

You might be wondering how long it takes to write a manual. The answer is that it depends on the manual. At one end of the spectrum is the manual that’s simply a binder containing drawings and specs from the company’s documentation system. That kind of manual can be slapped together in a couple of weeks, but it’s not going to be of much use to anyone other than a well-trained factory technician. At the other end of the spectrum is the fully-integrated manual containing installation and operating instructions, theory of operation, troubleshooting aids, repair procedures, and repair parts lists, all supported by photos and illustrations. A typical productivity metric for preparing such a manual is one page per day. Do the math – using that metric, with one tech writer working on a 200- page manual, it would take about seven months to complete the first draft. Using a more optimistic 6 hours a page, it will still take five months.

Allocating Technical Resources

The people who will be developing the manual will need drawings, specifications, and other design disclosure documentation. If they start writing before the product is released to manufacturing, they are probably going to spin their wheels. The writers will also need access to the engineers who designed the product. At some point, preferably well before the product is delivered, they will also need access to the product itself in order to take photos and validate operation and maintenance procedures that will be included in the manual. In an ideal world, work on the manual would not start until a production model rolls off the assembly line, but that’s not realistic. The way it typically works, is that the writers start work when drawings and software specs are released and then rely on the configuration control system to track the product as it evolves.

Knowledgeable engineers or other qualified technical people must be made available to validate the manual. There are two kinds of validation. The first is a desktop review for technical accuracy and completeness. There should be a sign-off by the responsible engineer(s) at this step.

The second, and arguably most important validation activity, is procedure validation. The preferred way to perform this validation is to have one person read the instructions, while a technician performs them exactly as read. It is important to control the process in this way because a knowledgeable technician is likely to take shortcuts or unwittingly compensate for deficiencies in the procedure. Another important part of the validation is making sure that controls and indicators called out in the procedures precisely match the labels on the equipment.

Until this point, the manual has been in a draft form, which is easy to review and mark up, but not suitable for delivery. Once validation is complete, a period of time is needed to incorporate corrections and last-minute product changes and then to format the material for delivery. If the manual is to be printed, printing and binding can add several weeks.

The main conclusion to draw from this discussion is that there are a number of serial activities that can’t be started until the equipment design is relatively mature, but must be completed when the equipment is ready to ship. This leaves a rather narrow window to accomplish a lot of work. If this work is not factored into the product planning, it will surely end up being a problem.

This article, and the two that preceded it, have attempted to provide an overview of the design and development processes for product support documentation. The goal of these articles was to help product managers and others who live outside the tech pubs domain understand how to procure and manage the operating and maintenance instructions needed to support their technical products. Future articles to be posted on this site will expand on these themes, and will also address the design and development of product technical training.


350 Feaster Road, Suite C

Website Design by Blue Ridge Solutions