Chapter 8: Document Management
"A memorandum is written not to inform the reader but to protect the writer." -Dean Acheson
The creation of large quantities of documents usually involves many people and processes. Eventually, management or the technical staff will recognize the need for good working practices for the document creation, development, and maintenance processes.
Like the management of any complex set of tasks, document management can benefit from sound general management practices. However, some notable practices specifically apply to document management. Two of these are the creation of project standards and the use of configuration management. These two practices apply to a variety of document creation and maintenance tasks. Good management principles apply to any type of electronic document project, whether delivered on paper or on-line. This chapter explores the application of these tools and techniques to document management.
The creation and production of documents in any large project takes a great deal of time, effort, and, ultimately, money. How can the process be controlled? What kinds of issues need to be examined? What parts of the document creation, production, and maintenance process must be managed?(1)
Let's break the document management problem into three areas (1) process: specific functions that must occur in a specific order to complete a document; (2) organization: functional responsibilities of people and management structure; and (3) system: technicalities of the electronic publishing system(s).
In the rest of this chapter, we examine project standards, configuration management, collaborative work, and document imaging. Each of these topics relates in various ways to the process, organization, and system issues outlined above.
Project standards form a bridge between the elements that make up a document and the capabilities of a publishing system. Project standards can also help clarify the publishing process. Configuration management defines the process used to create, maintain, and manage the documents. In addition, configuration management works within the bounds of the functional responsibilities of the people on the project. Collaborative work is the application of new technologies that help to integrate the work process of many people in a controlled manner. Finally, document imaging is a technological systemsoriented solution to problems with the management of existing document archives. Document imaging can help improve the management, use, and accessibility of these archives.
8 . 1 Project Standards
Establishing and using a set of project standards are the simplest things you can do to do improve the efficiency and quality of a project. An organization that produces documents that all follow consistent visual and structural conventions looks professional. Projects of any size, especially those that must be coordinated with a variety of departments and activities, can benefit from the use of project standards.
The term project standards, as used here, covers two areas: (1) those relating to the document themselves, such as layout and structural conventions and (2) those relating to the process of creating and producing the documents. The processoriented aspects of project standards are closely related to configuration management, covered in the next section.
Let's examine the specifics of what a project standard is and how to establish the usage of the standard. Realize that simply defining a project standard will not necessarily cause it to be used. Several components are needed to make an effective set of project standards. These are:
- . The project standard definition document.
- . An example that uses the standard.
- . Templates or style files in one or several electronic publishing formats.
- . Guidelines specific to the publishing system.
- . Environmental specifications such as fonts, printers, and operating system services.
- . An example that uses the standard.
Let's examine each of these components in turn.
DEFINITION DOCUMENT
The project standard definition document should be a reference manual in which users can quickly find answers to specific questions on formatting and style. It's desirable, if this manual is rarely used. Most of the time style files and the examples should be the main ways to use the standard.
EXAMPLES
Examples of the project standards should cover all the optional aspects of the design. For example, if either bullets or a bold font are acceptable for lists of information, present both alternatives. Along with the examples, there should be clear statements about recommended practices. For example, for software documentation, you may recommend that a brief description of each subroutine always precede the subroutine. These are not stylistic issues as much as issues relating to the actual content of your documents. Therefore, a separate "recommended practices" document may be necessary.
TEMPLATES OR STYLE FILES
Templates or style files allow users to "jump right in," creating documents that conform to the project standard. They are one of the simplest and most effective ways to improve the image of an organization's documents. A corporate look will give your project an aura of professionalism and make that first impression a good one.
Hire a graphic designer or consult your internal art department to design the look of reports, memos, and manuals. Don't assume you can do it alone. When a group of people work together, even loosely, it is possible to give an entire collection of documents visual coherence by using common styles. Common report covers and formats can, at the very least, give the impression that separately produced documents were coordinated and produced in a wellthoughtout fashion, even if they weren't.
The templates are much more than a mere convenience to users, although convenience is an important factor in gaining use of the standard. Templates provide a convenient way of encapsulating the project standard. Just as important, they encourage the use of the standard. Of course, if you have the luxury of mandating the use of the project standard, encouraging usage is not an issue. However, management chains are often not straightforward, especially in large organizations.
One individual should maintain the template files. Many people may have opinions about the style of the document. However, if versions of the templates start to proliferate, the project standard can disintegrate. Again, these issues relate closely to the configuration management of the documents.
PUBLISHING SYSTEMSPECIFIC GUIDELINES
Every document processing system has its own terminology and capabilities. The standardized usage of these capabilities will not necessarily translate well among various systems. Different systems may simply use different names for similar functionality. For example, WordPerfect styles are almost the same as FrameMaker tags. These systems provide different capabilities in the use of styles and tags, but the concept is fundamentally the same. Tags and styles are named, formatspecific constructs. The consistent and meaningful use of names is important.
Meaningful names will help people who are unfamiliar with the particular document styles use those styles more quickly. For example, naming a particular font style "emphasis" rather than "zowie" will help the uninitiated. Personal, "cutesy" names quickly become tiresome and are usually only meaningful to the select few people familiar with your idiosyncrasies.
Meaningful names are appropriate for virtually anything that requires a name. Thoughtful naming can make files, paragraph styles and tags, user variables, font variations, and other items more intelligible.(2)
In addition to meaningful names, publishing systems often have other capabilities you may wish to use. You can develop a projectspecific dictionary to ease spell checking. You can also create catalogs of styles and tags and make them centrally available. Specifying these items and providing easy access to them will make usage of these standard components convenient and prevent a proliferation of ad hoc solutions created by enterprising staff members. Again, these issues are part of an overall configuration management solution.
ENVIRONMENTAL ISSUES
Finally, let's examine the environmental component of a project standard. Environmental components are the operating system resources, printers, and publishing system installation options that are specific to your computer.
Probably, you work on one particular computer and use one particular printer, operating system, and publishing system. Most complex publishing systems have a variety of installation options such as languages, dictionaries, fonts supported, and so on. Different siteseven those that use the same electronic publishing systemmay have differences in operating environments. These differences can result in documents that are difficult to transfer from one site to another.
The environmental issues are insidious, because they are hidden from the user. Even experienced users are often not aware that these issues even exist.
The most common environmental differences are those concerning fonts. Don't assume that another location has all the fonts you are using. The project standard should specify the fonts, and you should make sure that all sites have access to the correct set of fonts. Printer description languages may be important if, for example, one site has all HP printers (PCL) and another site uses PostScript printers.
The five components of a project standard outlined above are not absolute requirements. Each project will have unique constraints and circumstances. You should view them as useful guidelines in the creation of your own project standards. Common sense is usually worth a shelf full of guidelines.
Along with the establishment of conventions for particular document processing systems, it is useful to establish procedures on how systems should be used. The process a document goes through is often as important as the content. Sign-offs, approvals, hand-offs, and so on are simply process conventions that clarify who is in control of what and when. Management must usually sign off and add feedback. Clear procedures and identification of what exactly must and must not be approved form the basis of an effective configuration management capability.
