As a member of a publications department, your charter is to develop, write, edit, validate, and publish documentation that supports the information needs of your customers.
This appendix provides guidance to help you meet the goals of that charter by giving you information on aspects of publications departments ranging from staffing concerns to technical review procedures. It is primarily intended for companies undergoing rapid growth in their documentation requirements. While most publications-related issues are covered, this appendix does not deal with general management issues such as hiring or personnel reviews.
Note - This appendix explains how the publications department fits into a software computer company's organization as an example, so you may have to modify some of the recommended processes and procedures to match your own situation.
For a list of books that cover the topic of management issues in more detail than can be provided in this appendix, see the section "Project Management" in Appendix A, "Recommended Reading."
The documentation presence in a company usually begins with a few people producing written material to accompany products. Publications departments can range from a single permanent publications manager working solely with outside contractors to a department featuring several writing, illustration, and production groups. Table B-1 describes the maturity levels of documentation organizations and their goals at each level. 
Use this table to see where your department fits on the continuum. When analyzing your organization, judge its performance as a whole over a long period of time. Although your organization may exhibit some features of a particular level, one instance does not define your organization as having achieved that level of maturity.
Table B-1 Process Maturity Levels of Documentation Organizations
Publications Transition to Project the Next Level Description Management Level ------------------------------------------------------------------------------------- Level 0: Unaware of the need for pro- None Staffing with Oblivious fessionally produced publications. professional Publications are produced by anyone technical who is available and has time. communicators Level 1: Technical communicators act None Development Ad hoc independently to produce of a style guide publications with little or no coordination. They may be assigned to different technical managers. Level 2: The beginning pieces of a process are None to very Introduction of going into place. Some coordination little some project Rudimentary occurs among the technical com- planning municators to assure consistency, but enforcement is not strong. Level 3: A sound development process is in Introduction Strong Organized place and being refined. People are of project implementation and being trained in the process. Project management of project repeatable management is in the beginning planning stages, with senior technical communicators learning the rudi- ments of estimating and tracking. Level 4: Strong project management is in Strong Beginning Managed place to ensure that the publications- commitment of the and development process works. to project implementation sustainable Estimating and tracking of projects management of more are thorough, and controls are in effective place to keep projects within processes budgets and schedules. Innovation gains importance within the strong existing structure. Level 5: Everyone on the teams is engaged in Strong Strong and Optimizing monitoring and controlling projects. commitment sustainable As a result, effective self-managed to project commitment to teams are becoming the norm. management continuous Innovations in the development pro- and process cess are regularly investigated and institution of improvement the teams have a strong commitment self-managed to continuous process improvement. teams
If you want to expand your department, the first step is usually to convince management of its value. However, measuring the "value added" of accurate, comprehensive documentation written by professional technical communicators is not easy. Your focus is on added ease-of-use for the user, in the product interface as well as the documentation, but that is often not as important an argument to management as actual costs saved.
This section provides some ways in which you can show how good documentation adds value, and some metrics from other studies you can use. 
Traditional accounting practices often make showing the benefits of improving quality very difficult. For example, many accounting systems still track costs by department rather than project. If customer support costs go down, the customer support group looks good. The documentation group doesn't get any credit for reducing support costs, even if good documentation contributed substantially to the reduction.
Many accounting systems are still based on a manufacturing model rather than a labor-intensive service model. For example, a documentation group that is measured only on pages per day appears to cost more if their higher-quality documents have fewer pages. Value that they are adding through activities other than writing and production (such as interface evaluation) or the greater benefits of shorter documents may not be reflected in the accounting reports.
Keep in mind that when considering the value added by a professional publications staff and good documentation, costs avoided are as significant as costs saved. For example, if a company gets 100,000 support calls a year at a cost of $30 a call, and if better documentation reduces the call volume by 10 percent (either the number of calls or a shorter duration of call), the technical communicators save the company $300,000 a year.
Another aspect you can point out is the cost per problem at different points in the product development cycle. Problems found in the writing/editing cycle are much less expensive to fix than problems found once the product is in the field.
Measures that show increased benefits resulting from good documentation include:
Measures that show reduced costs resulting from good documentation include:
When trying to find ways to illustrate value added by good documentation, consider the following techniques:
Companies, especially those with fledgling publications groups, often regard documentation as merely writing down what the product does. You should also try to establish a role as the user advocate, so that you can offer your expertise during the project development stage in areas such as interface evaluation, menu item and error message wording, usability, and so on. If you encounter resistance to early writer involvement, point out that problems like inconsistent interface features take much less time, and therefore money, to correct at early stages in product development than if the writers are not involved until the actual writing cycle begins.
Once you've convinced management that your department should be expanded, you may be asked to help determine how your publications department is funded.
Some possibilities are:
Obviously, there are advantages and disadvantages to each scenario. For example, if you are a writer reporting directly to an engineering project manager, you will probably have a closer relationship with the engineers on the project than if you are a member of a separate publications department. At the same time, your concerns as a publications-oriented team member might not be taken as seriously in an engineering group as they would if you reported to a publications manager.
Once you have permission to expand your staff, consider the roles your staff members need to fill. The following sections describe the roles of various publications personnel. Smaller departments or projects might need to combine these functions.
Once you've decided who's paying for the publications staff and what they do, you can start hiring them. One of the primary decisions in this area is whether to hire permanent staff or to use contractors. Small companies may choose to hire a documentation manager who supervises a staff of contractors; larger companies may have a mixed staff of contractors and permanent writers, or hire contractors for peak loads or short-term projects only.
Not only must you allow time for the contractor to "get up to speed," but the knowledge gained also departs with the contractor rather than benefiting the company.
Also, for editors especially, lack of familiarity with your in-house style and the lack of an established relationship with in-house writers can be difficult factors to overcome.
After deciding to hire a contractor, make sure that you consider the following:
If your company has a personnel office, hiring procedures are probably already established. However, if your hiring is less formal, you may need to consider: