B. Developing a Publications Department
After the documentation is delivered to production, your work is not done. You should have a plan in place to deal with last-minute product changes or inaccuracies in the documentation. Also, if the product documentation is likely to be revised, you should collect and maintain information that will help with the next version.
Handling Post-Production Revisions
Despite your best efforts, you may discover technical inaccuracies after the documentation is produced, either from omissions or from changes to the product. Therefore, allocations of monetary and staff resources to the project must continue even after the date the final documentation is delivered to production.
Typical ways to correct documentation inaccuracies include:
- On-line files on the product disks - These can cover documentation inaccuracies and last-minute product revisions.
- Replacement pages - Errors in limited locations in printed manuals can be corrected through replacement pages that are inserted individually by users. These generally ship with the product and are accompanied by a card or insert listing all replacement pages.
- Documentation update package - A last-minute change to the product that has ramifications throughout the documentation may require too many change pages to make replacement pages feasible. In this case, you may want to include a documentation update package, which explains the exact changes that need to be made to specific pages, including the paragraph and line location and the information to be added or deleted. However, this should be the solution of last resort.
Note - If your company sells directly to customers rather than through a third-party commercial distributor, you can issue change pages or update packages through your distribution channel or sales staff even after the product ships.
Make sure that customer support, marketing, localization, and sales personnel know about the inaccuracies and the steps taken to correct them.
Maintaining Project Continuity
Once a product has shipped, your first impulse may be to try to forget about it as soon as possible. This will only make your job more difficult when you have to revise the documentation for the next version. Some of the information you may want to save or document about a project includes:
- The location of on-line documentation files. Delete irrelevant files such as earlier versions of text or graphics. You may want to establish a central archive where final files are kept.
- While the details are still fresh in your mind, conduct a post-mortem meeting with the documentation team and write down a brief project review. Document anything that might be helpful, for example:
- Processes that didn't work as anticipated or could be modified to work better
- Controversies that arose (even if they were resolved, having a record of each controversy could prove useful later)
- Issues that affected the schedule that might recur during the next cycle
- Subject matter experts or other helpful project team members who were not official reviewers or project team members
- Technical review comments from all official reviewers.
- Edits or review comments that you didn't have time to incorporate for this version, but that should appear in a future version.
- Product information that you didn't have time to incorporate for this version, but that should appear in a future version.
