Technical Communication with a Purpose

Estimating Software Documentation Projects 101

Oh my gosh, my meeting is in 30 minutes and I need a doc budget!

The purpose of this article is to give you enough information about budgeting software documentation projects that you can quickly come up with a back-of-the-envelope estimate of the time and money required, something good enough for a preliminary project meeting. This quick estimate won’t be good enough for the real budget — for that you should select a technical writer or contract firm and get them to do a detailed estimate — but it’s enough to get you started.

Gold guy balancing time and money
How much money?

First off, the cost of a contract technical writer in the United States is between $70 per hour and $100 per hour. Below $70, you’ll probably end up with an inexperienced writer, like a new graduate or someone who’s been writing a while but isn’t very technical. Either way, you risk wasting time and ending up with a mediocre document. If a writer really knows your subject area and is very efficient you can consider going above $100, but there are plenty of talented writers available below $100 per hour. You shouldn’t plan to pay more without a specific writer and a specific reason.

Working full time, most writers can produce an average of 10 and 40 pages of documentation per week. That’s a big range, and the number of pages to estimate depends on both the writer and the material. For straight, difficult, technical API material, figure 10 pages a week. For simple, user-level material, figure 40 pages a week. If it’s something in between, like a programmer’s guide, or if you don’t really know, figure 15 or 20 pages per week.

That said, be aware that when the writer starts working on the project, you can’t expect the number of pages that the writer produces to be evenly spaced through throughout the project. Most of the start of the project is taken up with educating the writer and organizing the project. The actual pages won’t come out until the end. The first 25% of the project produces something like 5% of the pages. The middle 50% of the project produces about 35% of the final pages. The remaining 60% of the pages are written in the last 25% of the project time. Nerve-wracking? Yeah, tell me about it.

If you don’t know how to estimate the page count, take a look at an existing product of comparable complexity and scope. If you’re just planning web-based documentation, figure that every web page equates to about 1.5 printed pages. Estimate the number of topics, then double that for the topics you haven’t thought of and the navigation pages, and that gives you a reasonable estimate of the number of web pages you’ll need. Multiply that by 1.5 to get the paper page equivalent and then use that page count for your estimation.

A project example

Let’s work through an example. A product manager is planning a software product to compete with and replace the Brand X Doohickey software. He has a copy of the Doohickey manual set and there is an API reference manual of 50 pages, a programmer’s guide of 40 pages, and a user manual of 60 pages. The product manager, naturally, believes that his new product is easier to use, but he also thinks that the API has more features, so his new product’s API reference manual and programmer’s guide need to be longer. So he figures a user manual of 50 pages, an API reference manual of 60 pages, a programmer’s guide of 50 pages. He also wants a programmer’s tutorial/quick start guide of 20 pages. The list below shows how we translate this into hours.


    API Reference Manual: 60 pages / 12 pages per week = 5 weeks
    Programmer’s Guide: 50 pages / 15 pages per week = 3.3 weeks
    Tutorial: 20 pages /15 pages per week = 1.3 weeks
    User’s Guide: 50 pages /20 pages per week = 2.5 weeks
    Total: 12.1 weeks or 40 x 12.1 = 484 hours
    Figuring a middle-capability technical writer at $85/hour;
    484 hours x $85/hour = $41,140

In addition, include some time for changes, a ReadMe, and other minor documents, so go into the budget meeting estimating my documentation budget at $50,000 and then, if the boss whittles you down to $45,000, you’re still in good shape.

An important planning note: Whatever hours you’ve planned for your writer, understand that you’ll lose 25% of that figure in engineering time. The writer needs to talk to the engineers to understand the software and the engineers need to review the documents. If you don’t give them the time to do it—and require that they do it—it won’t get done and you’ll be waiting on the docs at the end of the project.

How much time?

After you do an expense budget, also do a time budget. You don’t want to find you have 500 hours of work to do and only have 200 hours for the writer to do it. Figure that the writer won’t really work 40 hours per week. They have other commitments and, quite possibly will get bottlenecked by insufficient access to the engineers. Figure they’ll work 30 to 35 hours per week. Use that rate to find the estimated start date for the writer.

You also have to include the time it takes to find a writer. That varies widely by the method you use to find and hire a writer. If your company has an existing relationship with a contract technical writing firm (like Expert Support!), then allow between two weeks and a month to do the project paperwork and reserve a writer appropriate to your project. If you can allow more time, you have a better chance of getting the ideal writer.

If you don’t have a specific writer in mind and your company doesn’t have an existing relationship with a contract technical writing firm (like Expert Support!) but you’re willing to use such a firm, then allocate a month and a half for the contract paperwork and selecting a specific writer from that firm.

If you have to hire an individual writer rather than one from a contract technical writing firm, allocate more like two to three months for advertising for writers, interviewing them, looking at their work, selecting one, negotiating contracts and rates, and working with procurement. It can go faster than that, but usually doesn’t.

OK, go to your meeting now

This should be enough information for you to block out the technical writing task in your budget and in your project plan. It’s not a real doc plan, but it’s good enough for the back-of-the-envelope planning that you need to do at the beginning of the project. When things get serious, well, schedule a meeting with a documentation manager or technical writer to get a more complete and detailed estimate. But this should be good enough for now.

Addendum: What if I just need an update to my doc?

Lots of technical documentation jobs are updates. Here’s how you adapt our estimation method for updates.

Try to get the technical source files to estimate how much has changed, as a percentage. Then double that, not because you distrust them, but because it’s human nature to think only of the things that have changed directly, and not to think of the things that are peripherally affected by the change.1 You should have a percentage. If it’s 10% or less, bump it up to 10%. Now multiply that percentage times the page count. Plug this page count into the method described in the main part of this article and you should get an estimate.

Let’s work through an example. You have a 150-page document. Engineering says that 20% of the manual has changed. Double that estimate to 40%. 40% of 150 pages is 60 pages. Proceed with your estimate as if you were estimating a new 60 page document. If this is of medium technical difficulty, then you can expect the writer to be able to do 20 pages per week, so this would be 3 weeks of work.

The only caveat is that after you calculate this estimate, also take a look at the number of screenshots and illustrations. Sometimes when you do an update, all of the illustrations are still good. Sometimes they all need to be redone because certain elements or words have changed. If the screenshots need to be updated, figure a half hour per screenshot.2 If illustrations need to be created from scratch, you need to get an estimate from the graphic artist—it’s too hard to estimate those without seeing them and getting some details.

1. These are mostly sections that refer to the new or changed capabilities, or should. But they also include cross-references, index markers, table of contents entries, and so on.
2. I know what you are thinking, “A half hour per screenshot? Isn’t that too much?” Nope. Screenshots aren’t that hard to take, but setting them up is time consuming. Often you need to make up sample data, make minor edits like blurring out names or adding drop shadows, get permissions on graphics, and so on. It’s a pain. Yup, a half hour per screenshot.

Douglas C. Shaker is Expert Support’s Vice President.

Tell your friends:
× is now Learn more