Documentation project metrics
Many factors affect the project time (and hence the cost), so it is not possible to quote a fee until we know more about your problems. However, we can give you guidelines that are based on previous documentation projects.
Project time
For every unique screen, dialogue box and tab in which users enter data, we estimate that on average 5 hours will be needed for documentation. This estimate is derived from the project data, which shows that over a variety of software documentation projects, we produced user documentation for 543 screens in 389 project days. In most projects, the range is between 2 hours and 7 hours for each entry screen.
In this initial estimate, we do not consider the complexity of the screens. All software has some screens that are relatively simple and others that are relatively complex, and we find that a simple count is sufficient to start with. We do not count read-only screens or informational messages.
For projects that are likely to be longer than approximately 20 project weeks, you should consider employing a full-time in-house technical writer. Use a specialist technical writing recruitment agency to find one.
Elapsed time
Producing high-quality software documentation requires a collaborative approach. Your team will need to answer our questions. If they do this promptly, then the turn-round time (duration) for a documentation project can be as short as 1.5 times the number of project days (for example, projects 3o and 2c). When we were waiting for answers, we were able to work on other aspects of the projects. This is the fastest turn-round you can expect.
Most projects last between 2 and 3 times the number of project days.
Sometimes delays occur, and even short projects take a relatively long time to complete, for example, projects 1p and 1o. In both cases, the software was simple and the project was simple, yet the duration was very long compared to the number of project days. The delays were because:
- Software was still under development and there were delays with upgrades
- Client staff were not available to answer questions
Project data
The following tables show historical data for some of our software documentation projects.
| Ref. | Unique screens | Document type | Pages | Project days | Duration (days) |
|---|---|---|---|---|---|
| 1p | 20 | User guide | 23 | 8 | 65 |
| 2p | 39 | User guide | 91 | 26 | 46 |
| 3p | 54 | User guide | 48 | 18 | 137 |
| 4p | 79 | User guide | 130 | 79 | 462 (66 weeks) |
| 5p | 110 | User guide + reference manual | 260 | 60 | 124 |
| Ref. | Unique screens | Document type | Topics | Project days | Duration (days) |
|---|---|---|---|---|---|
| 1o | 14 | User guide + reference | 17 | 8 | 186 (27 weeks) |
| 2o | 37 | User guide + reference | 31 | 46 | 425 (61 weeks) |
| 3o | 59 | User guide + reference | 100 | 54 | 83 |
| Ref. | Unique screens | Document type | Pages or topics | Project days | Duration (days) |
|---|---|---|---|---|---|
| 1c | 41 | User guide (print) + reference (online) | 34 (print) 63 (online) |
45 | 171 |
| 2c | 90 | User guide (print) + reference (online) | 32 (print) 118 (online) |
45 | 69 |
Other perspectives
Paper documentation takes about 3 to 5 hours a page and online documentation takes about 4 to 6 hours a topic according to Fredrickson Communications (www.fredcomm.com/showcase/guesstimating.html).
For high-tech industries, 7 hours a page is a reasonable estimate according to Hackos. (JoAnn T Hackos, 'Managing your documentation projects'. John Wiley & Sons, 1994.)
"The time it takes to design, lay out, write, and review a technical manual can be as high as 10 hours per writer per page" according to Altadero (www.altadero.com/sourceline.htm).
Writing and editing tasks alone add up to 13 hours a page according to Jody Lorig's Estimating Worksheet (www.techwr-l.com/techwhirl/pdfs/estimate1.pdf).
For an excellent discussion of issues related to estimation, see Geoff Hart's article on estimating project times and costs (www.geoff-hart.com/resources/2006/estimating.htm).
Finally, Dilbert's colleague Tina the Tech Writer explains why page counts are not a good metric for costings (www.dilbert.com/comics/dilbert/archive/images/dilbert2033335071127.gif).
RSS feed