Showcase: Articles

Stop Guesstimating, Start Estimating

By Joyce Lasecke, President

Note: This article 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.

Table 1. Things that affect time needed to complete a project:

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.

Table 2. Examples of hours-per-topic formulas:

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.
  

Reprinted with permission from Intercom, the magazine of the Society for Technical Communication.

Comments or questions? E-mail Joyce.

Check out Fredrickson Communications' Documentation Services.