Skipping Steps in the Publication Process

CIDM

December 2003


Managing Metadata for Responsive Web Sites with Subject Schemes


CIDMIconNewsletter Diane Davis, Director of IC Implementation, Technical Publications, Synopsys, Inc., with Chuck Millar, Editor, IC Implementation, Technical Publications, Synopsys, Inc.

Now that the economy is stalled, most companies are asking employees to achieve faster results with fewer resources. The pressure to quickly get products to market makes it tempting to skip routine processes and just get manuals “out the door” as soon as possible. Upper management often applies pressure, asking which steps in the process are “critical” and which can be left out. Is this a reasonable approach to producing documentation? Are there steps that can be left out without having a deleterious effect on the documentation? Although you can sometimes get lucky and produce high-quality documentation without following all the usual steps, routine processes give you confidence that the documentation will have accurate and complete information delivered on time. Here are some questions to help you determine what are the essential processes in developing documentation.

Evaluate Your Process

People often think that detailed planning is not necessary. Do your writers create documentation plans? How much information do they have when they write those plans? Do they get buy-in to their plans from the appropriate people? Forces outside the publications department can cause problems with obtaining accurate and complete information as well as with meeting deadlines. Does research and development (R&D) provide functional specifications, and are these specifications usually complete? Is there a functional specification for each new feature? How late in the release are changes made to the content of the release? Was R&D overly ambitious? Were new features for the release pulled at the last minute because the coding or testing was not completed? Dropping content at the last minute can be easier than trying to add it. In either case, late changes are problematic.

Quality checking is another area often considered unnecessary. How do you judge the quality of your manuals? Somewhere in the process, the quality should be checked. Customers usually rate technical accuracy as the most important documentation requirement. How carefully were your documents reviewed? Do reviewers provide useful information, or do they just perform a perfunctory review-do they review the documentation at all? Are your manuals edited? Do you have a style guide to ensure consistency and proper use of terminology? Do you support the editing process and make sure the style guide is followed? Do writers verify that the editorial changes do not change technical accuracy? Do you have a final sign-off procedure?

How does your upper management view quality? Are you told to produce documentation fast, even though you know it will be inadequate, and that later you will be able to fix it? What effect does poor documentation have on the success of the product or on your support center’s ability to provide service to customers and keep them happy? What are the direct costs of rewriting the documentation, and what are the hidden costs when other product schedules are affected by having to rewrite rushed documentation?

Learn from Experience

At the end of each release, do you hold a lessons-learned meeting to give your staff members the opportunity to brainstorm about problems encountered in the release? Do you take these evaluations seriously and follow up on the suggestions?

Having a clearly defined set of steps in your process allows you to review each step as part of a continual process of improvement. Determine what went well and brainstorm how to improve it. If there are problems, evaluate what went wrong and correct them for the next release. Is there a reason why a specific step is done? Where does the output from each step go, and does it contribute to the end result? Have you incorporated new technology without changing the steps in your process to account for the new technology? Sometimes a change in technology will completely change your process or some parts of it. Are you following a process just because you have always worked that way? Make sure there is a good reason for each step in the process.

Make Informed Choices

So the question remains, when is it appropriate to skip routine steps to get manuals out the door fast? To answer this question, you have to make a decision about what you are willing to sacrifice. Sometimes it is possible to skip a step or to combine some steps to meet a tight deadline. Instead of having two edits, edit only once. Instead of giving reviewers a week to review the document, give them a shorter time. Or hold a review meeting to get everyone’s comments on the same day and to resolve any conflicts on the spot.

Although it is always a judgment call whether to skip steps when you are under extreme pressure, you can make a much more informed decision if you have a clearly defined process that has a built-in component for evaluation. You will then know which steps are most important, and you will have records of what has worked in the past.

One of the main temptations you may experience when you are under constant time pressure is to neglect the whole area of process development. You may find yourself so busy meeting deadlines that you never stop to evaluate the steps you are following to meet those deadlines. Although there might not seem to be time in your schedule to examine and improve the process you follow in producing documentation, in this area an ounce of prevention is worth a pound of cure. Taking the time to develop effective processes will be much less expensive than dealing with the results of missing deadlines or producing documentation that is either inaccurate or incomplete. CIDMIconNewsletter

About the Authors

Dec0315 Dec0320

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close