• Assessment of the firm and task performance/requirements
  
  
• Type of documentation:
  
  
  • Technical Reference
    
    
  • User-oriented
    
    
• Standards
  
  
• Environment and external resources required (editors, graphics staff, management, etc.)
  
  
• Graphics required (number, detail, original art)
  
  
• Production/printing costs if not internal to client firm
  
  
• Edit & review process (client and writer)
  
  

• What document is involved in the specific task?
  
  
• What documentation or material exists to support development of the new document?
  
  
• How much of the existing documentation need will require changed/revision if being used or the subject?
  
  
• Is there an electronic version of the existing documentation?
  

This is all part of what I call the “intelligence collection process” that allows a better scope of the task and, of course, ultimately, a better estimate. When I go into a firm (as a contractor) I begin this information collection during the interview process, not after I accept the job. Why? First, I gain insights to the task right from the start by asking some pointed questions. Second, it allows me to assess whether I even want to take the assignment. If I discern genuine management interest in documentation is lacking, I may refuse the job entirely. Who needs that problem? Naturally, a staff position allows direct insights to the whole process internally and makes the estimating process that much easier.

• Technical reference, and
  
  
• User (or tutorial and help)
  

Where and how it is to be used (environment) is a factor, so we have external and internal. Understanding these differences provides a guide to what is included.

External documentation is intended for audiences outside the corporate or organizational environment in which it was created. Generally, it is more expensive to produce, and is a marketing tool as well as an operations tool. This type of documentation is highlighted by the use of high-end graphics and attractive packaging.

Internal documentation makes up the bulk of all documentation, but usually is the poor cousin of external material. It frequently fails to get the necessary time, money, management support – and thus attention – because it is only used within the organization and has a murky relationship with profit.

• Insure early interaction and detailed coordination between management, analysts/managers, and the documentation staff.
  
  
• Establish a focal point for each document project.
  
  
• Reduce problems implicit to multi-author / multi-source input scenario.
  
  
• Integrate detailed review, validation, and edit in production process.
  
  
• Reduce production costs by establishing a standard format for overall documentation and specialized input materials.
  
  
• Promote the effective coordination of the people and other resources implicit to documentation production process.
  

Establishing a “standard” format for documents reduces cost by streamlining the production process and, consequently, directly impacts the estimate process. If the client has a standard or style guide, it speeds the process by eliminating some of the pre-writing steps.

Estimate Implications
Technical reference material is generally less costly to develop because the higher end graphics, quality paper and printing, etc., are not required. On the other hand, difficulty gaining access to the developers and less than ideal management support increases costs.

User documentation, e.g., Users Guide, is more expensive to produce because more upscale graphics are required and usually a more expensive printing. Graphics take time, whether screen captures with annotations or more complex system diagramming, and may require specialized software (PhotoShop, Paint Shop Pro, Visio), adding to costs. Some firms acquire a contract/permanent graphics/design person to develop this portion of the documentation. These factors increase development time and thus overall production costs.


DOCUMENT COST ESTIMATING:
Much of the process of estimating the cost for documents naturally depends on the corporate environment, overhead costs, process, and corporate structure. There are many variables so the approach here is to attempt to identify as many of the basics with some of the subtleties and work from there.

• Writers,
  
  
• Graphic Artists (for “art”)
  
  
• Typists (also “formatted” document somewhat)
  
  
• Editors
  
  
• Production (Printing)
  

Today, as we know, the Technical Writer usually wears more than one hat, meaning they do document design and formatting, interviewing, graphics, indexing, and a variety of other tasks involved in the process.

An old “rule of thumb” for documentation was to project a total of about 8 hours for each page to take it from the first word to final product. This allocation included time from other parts of the documentation process and thus different costs. Style Guides were frequently used to establish the format, content, and usage for these documents, and roughly correspond to what we call standards today.

Estimating Costs Today
Before discussion of techniques for estimating documentation development costs it should be clear that the information presented earlier in this chapter directly impacts any estimation effort. In addition, documentation has taken on some newer forms, including online Help and Web-based materials.

Standards remain important to cost reduction and should not be ignored. The majority of the available software packages have features to developed “canned” formats (templates) for documents. My approach, as a consultant, has been to develop templates with formatting and outline for each of the individual documents in a “library” of typical system and user documentation. Experience has shown this is not only responsive to the standardization requirements and results in cost reduction, but dramatically expedites my development effort by reducing lead time. Clients really appreciate this. Granted, there were development costs I had to bear initially (primarily time which = $$$, even for a consultant), but they have long since been recovered.

• Technical Reference
  
  
• User
  

a) Technical Reference
Technical reference material (system-oriented documentation) usually requires the writer to access the developers/programmers for interviews, in-process discussions, and review. We also need to consider which document in the library of system documentation is in question since some require more time than others. In addition, software is frequently still in some phase of development or modification, and there is implications on the writing project from this. The “size” of the system is another factor, as I mention earlier. Developing a document for a system with a million lines of code is quite different than for a system a quarter of that size.

So, we get into some fuzzy areas. How big will the document actually be? No small part of estimation in this respect is based on experience. There’s no clear cut answer. On the other hand, we can look at the time generally required to develop a single page:

These estimates assume a standard or established format and outline for the document. There are other variables too, such as the experience of the writer, technical background, time involved with system or project.

2) User Documentation
User documentation is another story, essentially dealing with factors different from the technical material. There must be a focus on the audience needs and background, use of graphics (“A picture’s worth a thousand words!”), and keeping it simple. Familiarity with the user interface for the software is beneficial, but access to a knowledgeable user is important too.

Exploitation of screen captures significantly enhances the document and reduces graphics time.