Making Accurate Project Estimates


April 2001

Making Accurate Project Estimates

CIDMIconNewsletter Sheri Watkins, Manager, Technical Publications, Sabre, Inc.

Sabre Inc. develops computer software applications that support the travel and transportation industry. The technical writers in our documentation department design and develop printed user guides and online help systems that help our users make effective decisions while using our software to manage their airline operations.

We track effort via the number of hours we work. Many of our projects have limited funding, which increases the importance of creating accurate estimates and then completing the work within the estimated number of hours.

In the past, we might forget to allocate time for certain tasks, or we would be near the end of a project before we realized we were out of hours. Therefore, we implemented processes and templates that make it easy to gather information about a project, feed the information into an estimate of the work effort, feed the estimate into a project plan, and then maintain the project plan to manage our work. The figure below summarizes the process. This process has helped us accurately estimate and manage our work. If for some reason we are running behind on our work, our processes allow us to recognize the problem early enough to make adjustments and still meet our budget and deadline.

Gather Information

Before we can estimate work, we must gather information. To improve our understanding of the application’s capabilities, we obtain and review all available information, including functional specifications, design documents, release notes, and/or a list of enhancements. We also interview the subject-matter experts (SMEs).

The SMEs provide us with a demo of the application’s functions and explain the business need the application fulfills. They work with us to prepare a list of tasks the user performs. In most instances, the SMEs have been to customer sites during the scoping study, requirements definition, and design phases of the development cycle; consequently, we rely on them to convey as much information as possible about our users. Unfortunately, our writers do not normally have access to our users.


Estimating Process

We have a workbook of questions we use while reviewing available information and interviewing the SMEs. The content and order of the questions allow us to easily feed the answers into our estimating spreadsheet. There are typically one or more questions related to each line item of the estimate. For example, here are a few of the questions we ask to determine the size and complexity of the application:

  • What is the total number of windows to be documented?
  • What is the average number of fields on each window?
  • What is the maximum (and minimum) number of fields that can appear on a window?
  • Do the same or similar fields appear on more than one window? If so, explain.
  • Is prerequisite data required for certain windows (built on previous inputs from other windows, databases, and/or files)?

After we complete as much of the workbook as possible, we use the information and task list to prepare an outline. The comprehensiveness of the outline or design varies according to the amount of time we have to produce the estimate and the desired level of accuracy.

Next, we use the workbook and the outline or the design to prepare an estimate.

Preparing an Estimate

Everyone naturally focuses on actual writing time when preparing an estimate, so it is easy to overlook non-writing tasks. Therefore, we use an Excel spreadsheet that allows additional time for all of the work required in the documentation process.

The spreadsheet is divided into several phases. Each phase consists of one or more tasks (or line items). Each task has columns for the estimated number of hours for the writers to accomplish the task, the estimated number of hours for the developers to accomplish the task, a metric, and an explanation. We use the metrics as a baseline. Each project has unique requirements, and we carefully review each task to determine whether we need to increase or decrease the metric to account for these unique requirements.

The remainder of this section describes each phase in our estimating spreadsheet process. As we walk through each of the phases, you will understand our estimating techniques and workflow processes.

Phase 1: Research
The Research phase includes everything we do before we actually start outlining the document. We include hours for the time we spend reviewing any existing documents and attending a demo.

Depending on the platform and complexity of the application, the amount of time it takes to gain access to the application from the writer’s workstation varies significantly. For example, if a writer has never worked on a mainframe system before, we may need to order and install emulation software to run the application from the PC, obtain a user ID from our security department, obtain access rights to the application, and obtain proper database access. Our workbook contains specific questions about the application platform and installation so that we can allow ample time in our estimate.

We allow time for project management set up. As we work, we record the hours spent against a client-specific project code that facilitates billing. We allow time to submit the form to set up documentation phases within this code. The phases separate writer hours from developer hours. Then we write a project definition document that defines what will be delivered, how, and when. We also create a project plan.

Phase 2: Create first draft
The Create first draft phase includes the time it takes to outline, design, write, and edit a first draft of the document.

For our hardcopy user guides, we base most of the metrics in our estimate on the number of chapters in the document. To do this successfully, we assume that our standard chapter takes 40 hours to write, represents average complexity, contains approximately 30 to 50 pages, and describes approximately 4 to 6 major windows and 4 to 8 minor dialog boxes. A major window allows a user to perform several tasks, where a minor dialog box is one that has only two or three choices (such as a confirmation dialog box or a dialog box that allows the user to Continue/Save, Quit/Exit, or Print). Based on the outline and our completed workbook, we alter the metric of 40 hours per chapter to accommodate the variance.

We allow time to capture, edit, import/link window images, draw diagrams and illustrations, and create a table of contents and an index.

Before the first draft is considered complete, we submit it for editorial review, incorporate the review comments, and print a draft.

Phase 3: Conduct technical reviews
Our documents go through one to three technical reviews. For each technical review cycle, we allow time for the SMEs to review the document for technical accuracy and time for us to incorporate their review comments, perform an editorial review, and incorporate those review comments.

With each subsequent review, we reduce the metric by about 50 percent. For example, if we allowed 3 hours per chapter to incorporate review comments for the first technical review, we might reduce this number to 1.5 hours to do the same for the second review.

Once we incorporate the final technical and editorial review comments, we regenerate the table of contents and index and reprint the document. At this point, we consider the document complete and ready for delivery.

The remaining phases focus on miscellaneous tasks that occur outside the actual writing and review cycles.

Phase 4: Rework
Everyone knows that if developers make changes after a writer completes a section or topic, the project will be extended. However, while implementing a change management process to handle scope changes is appropriate for changes of significant size, there are also many small changes for which this is not appropriate. We would bury ourselves in paperwork if we implemented our change management process for every little change that is made.

To avoid this problem, the Rework phase of the estimate allocates time for minimal rework. We allow 6 percent of the subtotal from Phase 2: Create first draft as a starting point and alter this number up or down depending on the stage of the product development cycle when we begin work.

Phase 5: Project management tasks
The Project management phase allocates time for all of the effort involved in managing the work throughout the life of the project.

We allow 5 percent of the time spent in Phases 1 through 3 for project meeting time. This includes a kickoff meeting with developers and writers at the beginning of a project to make sure everyone involved in the project understands what is expected. We also allow 15 percent of the time for project managers to ensure that we have enough resources assigned with an appropriate skill level and for a project office analyst to track progress against the project plan.

Because writers are all unique individuals, we allow 5 percent for resource profile variances. We alter this metric based on two variables:

  • Effort variance factor, which represents the assigned writers’ skills and knowledge of the application, industry, and writing tools.
  • Work interrupt factor, which represents the assigned writers’ non-project activities (such as computer downtime, telephone calls, and responding to email) and loss of productivity if they are assigned to more than one project. For example, if they are assigned to a project for three-fourths of their time on that project and one-fourth of their time is spent on a second project, changing back and forth between projects could result in up to a 10 percent loss of productivity.

Phase 6: Production and completion
The Production and completion phase allows time for production (copy, bind, and ship) based on the desired number of copies. We also allow time to complete our final checklist, which includes cleaning up project files, archiving the files, closing out the project in our project database, updating the metrics database, and sending out satisfaction surveys. In addition, we conduct a project evaluation, which helps identify what we did right during the project and what we could have done better.

Estimate Verification and Approval

Once we complete a draft of the estimate, we validate it:

  • We search our metrics database to find past projects that are similar in complexity, number of user tasks, number of windows, and/or available existing information. We compare the overall number of hours it took us to complete these projects to the hours in our draft estimate. If necessary, we alter the estimate.
  • We divide the number of hours in our estimate by the number of pages we think we will have in the finished document. We compare this number to an industry-accepted hours-per-page estimating metric. We have to be careful because some industry metrics do not include everything we include in our estimates. Therefore, before we compare, we subtract hours for some of our tasks (such as our resource profile variances) to compare “apples to apples.”

After we are comfortable with the estimate, we submit it to the project manager for approval. Once approved, the hours estimate becomes our budget, and we give the estimate and document outline to our project office analyst.

Create a Project Plan

Our project office analyst uses a project plan template in MS Project where each task correlates directly to the line items on the estimating spreadsheet. She takes the number of hours from each line of the estimate and enters that number into the project plan against the matching tasks.

If we have more than one writer assigned to large tasks, the project office analyst breaks the number into smaller tasks assigned to each individual. Then, when one writer’s work is finished, the task can be closed without having to wait for the other writer to finish.

For example, if the number of hours estimated to outline and write the document (line 1 of Phase 2) is large and represents more than one writer, we insert tasks assigning each chapter to the appropriate writer.

Writers use the hours in Phase 4: Rework whenever they have a minor change to make as when a developer changes the code. We consider changes that take less than two or three hours to be minor changes, but it really depends on the size of the project.

For the hours allocated to project management tasks, we create monthly tasks for projects of long duration to avoid having tasks that go on for long periods of time and do not get closed.

When we complete the project plan and the scheduled number of hours equals the estimated number of hours, the project office analyst baselines the project and begins to track actual effort.

Manage the Work

As writers work on the project, they submit weekly timesheets and status reports to the project office analyst to track the actual hours worked. When the writer completes the work on a task, the project office analyst closes the task in the plan.

At the end of the project, the project office analyst closes the final task(s), archives the project plan, and archives the project files. We use the project plan in our project evaluation to determine if the actual hours spent for each task is similar to the hours allocated for that task in the estimate.


A few years ago, we thought our estimates were accurate. We had a project plan that was created independent of the estimate. If projects were over or under budget, we did not know why, because it was difficult to compare actual time spent with the amount of time estimated for that task. Therefore, we decided to create a more effective project plan template.

Merging these processes improved our ability to estimate and manage our work as well as to work smarter. If a project is over budget on a certain task, we know immediately and can react quickly to make appropriate changes. We can identify the reason and look for ways to avoid going over budget on future projects. If a project is under budget, we can identify the reason and try to repeat it. If the variances show trends across many projects, we can easily recognize estimating errors and make adjustments to our estimating default metrics. CIDMIconNewsletter