Estimating Tech Writing Jobs

Home About Articles Graphics Pens

Overview:

One of the more challenging parts of being a contractor or managing a writing project is developing an estimate of the fee or costs. Sure, there are various techniques out there, some more accurate than others, but generally no hard and fast rules applicable across the spectrum of potential assignments.

Therein rest at least part of the key to doing a viable estimate, i.e., what kind of document development are you doing. I look at more than that, including the following:

  • 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)

ESTIMATING KEYS:

Assessment of Firm Environment and Requirements

Permanent employees (managers) have the advantage of knowing the pros and cons of their work situation, issues likely to slow or impede the work, resources available, and whether there will be relatively easy access to developers and managers. Generally, there will be more than one task for the documentation team at any given time, so loss time/wait time need not be there – given adequate planning and scheduling – but usually sneaks in along the way.

If the task is to develop technical reference material, access to developers is a key issue in the majority of tasks and must be factored into any document development process. Another factor that directly impacts development of technical documentation is the extent to which the developers have commented their code. If automated development tools have been used (e.g., CASE) this may prove less a factor. may be diminished somewhat, but developers tend to have very little demonstrable interest in documentation.

The next thing to look at is trying to get a reasonable understanding of the size of the project, system, and the documentation component involved in the task. Clearly, an application with a million lines of code requires much more documentation than one with 250K lines. Ask the questions:

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.

Type of Document

Documentation is generally classified by content:

  • 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.

Documentation Standards

What do documentation standards have to do with costs? Standards do the following:

  • 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.

Rules from Another Time

Documentation development has transitioned dramatically with the availability of wordprocessing and graphics software for the PC and Mac. Prior to this, documents were developed by a team, consisting of:

  • 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.

Costing Details

There are two classes of documents I consider here:

  • 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:

ACTION
Time Req ’d/Page (hrs)
Interview/Discussions
0.5 – 1.0
Draft
1.0
Graphics (1 every 2-3 pages min.)
1.5 - 2.0
Edit/Review
0.5
Index
0.25
TOTAL
3.75 - 4.75

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.

ACTION
Time Req ’d/Page (hrs)
Interview/Discussions
0.25 – 0.5
Draft
0.5 - 1.0
Graphics (1 every 2-3 pages min.)
0.5 - 1.0
Edit/Review
0.25 - 0.5
Index
0.25
TOTAL
1.75 - 3.25