Note: This article is republished with permission from Intercom, the magazine of the Society for Technical Communication. It was originally published in May 1994 and focuses on creating user documentation concurrently with software development.
If you’ve ever prepared a cost estimate for a project, you know that you can lose sleep over it. Did you think of everything? Have you uncovered the true complexity of the system? You can reduce anxiety by following a process that answers these questions and results in concrete and measurable information on which to base your estimate.
- First, you need to define the project thoroughly.
- Then, you can calculate project hours using formulas and other historical information from previous projects.
- Finally, you need to assess the risks of changes that affect your estimate and adjust it accordingly.
This article explains these steps and provides some specific estimating formulas that may work for your project.
Defining the project
A certain amount of analysis and planning needs to be done before you can estimate the work effort involved. Learning about the audience and the system is the first step. This research will enable you to determine the project scope and prepare an outline of each deliverable.
For example, let’s say that you will be developing a context-sensitive help system. Based on your understanding of the audience’s information needs, you can identify the types of help topics you’re going to provide, such as field help, procedures, and window descriptions. Then, based on your knowledge of the system, you can identify how many of each type of topic you’ll be writing. You’ll base your estimate on this concrete information.
However, the scope of the project is just part of what goes into an estimate. The people involved in the project and the process they follow will affect the hours needed to complete the project as much as — if not more than — the amount of material to be written. Table 1 contains some questions to answer about the process and people. What’s important here is to recognize any elements that are not “business as usual” for your department or company. As I’ll explain later, you’ll need to evaluate those elements to determine whether to adjust your estimate.
If you don’t already have the answers to these questions, ask for the time (and, if applicable, budget) to conduct what we refer to as a “design phase.” This phase can encompass needs assessment, audience analysis, project definition, and prototyping. It results in a blueprint for the deliverables and a work plan for the project. And, of course, it includes the cost estimate for developing the deliverables.
[rs-space space=”30″/]
Table 1. Things that affect time needed to complete a project:
[rs-columns gutters=”no-gutter”]
[rs-one_half]
PROCESS
System development: What is the development, testing, and implementation plan? Is it progressing on schedule? Is the design stable or changing?
Source material: Are there any written design specs? Are they accurate and up-to-date? Will a test system be available to writers?
Schedule: Is there a reasonable amount of time to complete the project? Or do many tasks have to be compressed into a very short time?
Review cycle: How many reviews will there be? Will someone from the client’s staff serve as a referee to resolve conflicting review comments, or will the writer need to serve this role?
Tools: Have you previously used the hardware and software for documentation? Is technical support available? Have you worked out bugs for importing graphics, creating an index, or creating online help?
[/rs-one_half]
[rs-one_half]
PEOPLE
Documentation team: How many team members are there? How experienced are they with the subject matter and corporate culture?
SMEs (Subject Matter Experts): How knowledgeable are they? Will they be available to answer questions several times a week? Are they supportive of the documentation effort?
Reviewers: How many are there? Are their roles defined? Are they likely to do their job?
All parties: Is everyone fairly united over approach and goals? Or is there a sticky political situation?
[/rs-one_half]
[/rs-columns]
Calculating the estimate
At our company, we have developed formulas to estimate hours needed to develop content—this accounts for research and writing. We use a different set of formulas for paper materials than for online help. For all the other tasks on a project, we follow some general guidelines that apply whether the deliverables are paper or online.
Formulas for writing paper deliverables
We estimate writing time based on a number of pages. This is fairly standard among companies that estimate projects. We use a range of three to five hours per page for a two-review cycle. Consider the content when deciding on the hours-per-page formula. We have found consistently that step-by-step procedures require more hours per page than most reference information, so we use a different hours-per-page ratio for each type of information.
Formulas for writing online help
In the past, we used our hours-per-page formulas for estimating online help development. After gathering four years of historical data about hours needed to develop help systems, we have come up with the hours-per-topic formulas shown in Table 2. If you have no historical information of your own, feel free to try using these formulas. However, it’s important to come up with formulas that reflect your work situation.
[rs-space space=”30″/]
Table 2. Examples of hours-per-topic formulas:
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[rs-responsive width=”760″ display=”show”]
[rs-space space=”-15″/]
[/rs-responsive]
[rs-responsive width=”760″ display=”hide”]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
Type of topic
[/rs-one_half]
[rs-one_half]
Guideline hours
[/rs-one_half]
[/rs-columns]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-responsive]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Step-by-step procedures
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
4 to 5 hours per procedure
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Glossary terms and definitions
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
0.75 hours per term
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Reference topics, such as explanations of concepts or theories, overviews, and product information
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
1.5 to 2.5 hours per topic
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Window descriptions that cover function and navigation but do not include field descriptions
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
Per window:
- 3 hours—text only
- 4.5 hours—includes screen capture and cleanup
- 6 hours—includes screen capture and cleanup, scaling the images, and/or applying hot spots
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Field descriptions
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
1 hour per field
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Button descriptions
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
0.25 hours per button—includes the graphics of the button
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Contents window
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
Minimum of 4 hours
(Additional time will be required for creating *.CNT format files for Windows 95 (or NT) Help)
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Search facility (customize, add to, and review)
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
20-40 hours total
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
[rs-columns gutters=”no-gutter”]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Type of topic
[/rs-responsive]
Time to create or modify graphics other than screen captures. This task includes steps like the following:
- Capturing icons, cleaning them up, and including them in files
- Creating icons
- Creating diagrams or other graphics
[/rs-one_half]
[rs-one_half]
[rs-responsive width=”760″ display=”show”]
Guideline hours
[/rs-responsive]
0.5 hours per graphic object
[/rs-one_half]
[rs-divider type=”solid” brd_width=”1″ brd_color=”#FFFFFF”/]
[/rs-columns]
Guidelines for other tasks and roles
For the other roles on a project, we use these guidelines:
Project leader: 15-20 percent of all other hours
Editor: 6-8 printed pages per hour, or 8-12 help topics per hour
Also remember to estimate time for other tasks for which writers are responsible. Here are some examples:
- Participating in system design meetings
- Testing the software (either formally or to make sure what you wrote is accurate)
- Maintaining issues lists for the software development team
- Participating in regular status meetings
- Preparing meeting minutes
Fine-tuning the estimate
After you’ve calculated hours for each line item in your estimate, look at the hours in the context of your project. Your goal is to determine whether the hours you’ve estimated are sufficient for the circumstances. There are two activities you should do to “test drive” your estimate.
First, lay out the hours over a time period so that you can see whether the work can be accomplished by the deadline with available staff. If you find that you need to add staff, figure out what that means for your estimate. Increased project management time for the extra coordination? Learning curve time? More hours allocated for status meetings?
Second, think about what would cause your estimate to be too low. What circumstances are beyond your control, and how likely are they to create problems for you? Such circumstances can be anything from scope changes to unavailable subject matter experts to political battles. You can address these in your estimate in one of two ways:
- Identify the risk in the list of written assumptions on which your estimate is based. This is appropriate for ensuring that you can renegotiate the estimate if the scope changes, system development dates change, reviewers don’t respond on time, or other circumstances change.
- Adjust the estimate to accommodate the risk and its implications. For example, if you know that the test system is often unavailable for days at a time, you may need to add hours to the project for the writers to gather and test information in more time-consuming ways. Or let’s say there is a high level of mistrust and animosity between two key managers due to issues regarding system design. You might want to allow for the possibility of another review and revision cycle to iron out conflicting review comments. This cycle could increase total project time by 15 to 20 percent.
You can now present the estimate to your client or manager with a high level of confidence. Your estimate will be credible because it is based on concrete information that defines the scope of the project. And it will be comfortable for you because it accounts for the intangible risks that you’ve anticipated. Finally, your list of assumptions gives you the grounds for renegotiating the estimate if any of those assumptions change.
Should you provide a cost estimate?
Sometimes projects are so undefined that it’s impossible to provide a valid estimate for completing deliverables. However, you can still provide some budgetary information without committing to finish work within a particular budget or time frame. Here are two approaches:
- Provide a time-and-materials quote based on working at an hourly rate for the duration of the system development project.
- Provide a sample estimate for a hypothetical deliverable, but work on a time-and-materials basis. The sample estimate at least gives the client or manager some sense of what it takes to develop documentation.