Estimating documentation costs for a technology project that you're managing seems like it's almost outside the realm of possibility, like finding the perfect hamburger or a jacket that fits you just right. Like clothing and food, there isn't a "one size fits all" amount of hours that your company can estimate for each project, because each project and each writer are different.One or more of the following situations may apply to your current project:
* Your firm employs one or more freelance or contract writers who telecommute most of the time, and they don't work on a regular nine-to-five schedule. Therefore, getting information from them can be more difficult.
* You have one full-time employee working as a lone writer, or you have a team of writers, but none of them have ever tracked their time on documentation projects before, because they're just too busy working.
* You're working on several projects at once, each with different requirements: You're creating print documentation for a hardware product, a PDF file and online help for a software product, and updating a product Web site with updated information and online training. These different projects can make it difficult to estimate costs for each one.
* You are (or plan on) incorporating usability studies and testing as part of project development. A usability study and testing involves the entire project team, and possibly people outside the project team. You will need not only to estimate usability study and test time and costs, but also the time and costs incurred to anyone outside the project team.
No matter what situation you find yourself in, it's always difficult to figure out where to start. The answer is easy: Start with your project team.
Do your homework
When the powers that be ask you for estimates and deadlines, you need to schedule time to meet with your entire project and documentation team in person, so that you can focus them on the task of estimating costs and allow everyone to share ideas.
In preparation for this meeting, have an agenda, as well as suggestions for metrics that your team members can wrap their heads around. For example, if people on your team aren't aware of how productive they are, ask them to remember back to the time spent on past projects to provide an approximation of what they can do.
For example, in your last project your documentation team may have been able to write and edit the content of one 8.5-by-11-inch page in one day. From that, you can determine how many words are on that page, and then determine how much time it will take your team to write so many words (or pages).
If you're using a freelance writer or a writer who has her own business, they need to know how much to charge. For your freelance writer or a writer with a business to provide an accurate quote, ask the writer to complete some homework of their own to bring with them to the meeting. You can give them suggestions to get them started.
For example, have them look at other companies that provide similar services; research salary surveys online, such as the technical communicator contractor survey produced by the Society for Technical Communication; and view mailing lists and newsgroups such as the TECHWR-L mailing list for technical communicators.
The ever-changing product
If at all possible, learn about the changes that will be made in the product during development, and what effects those changes will have on your deadlines and cost estimates.
For example, in a software product you may have two buttons. Button A brings up four choices, and Button B brings up five choices. However, if the button functionality changes during the development process and you're not aware of it, you or your customers could suddenly discover that your documentation for the final product is incorrect.
Therefore, it's important to have your project and documentation teams meet regularly and make updating information a high point of each meeting agenda. You don't want your customers or stakeholders pointing out documentation problems that should have been avoided during the development process.
Document the documentation
Another important asset that you need to bring with you to each meeting is a checklist of everything you need for your project documentation, which you should create during the first project development meeting. Share the checklist with the rest of your project and documentation teams at each meeting, so everyone understands what features are supposed to be added.
Keep a master copy of this checklist for yourself. If any team member has additions or changes to the checklist, have the team member submit the changes to you for your review. You may need to review the change with others inside - and perhaps outside - your project team.
Once you determine that the changes are needed, distribute a new copy of the list to the project team, including the documentation teams. Be sure that they also understand the effects that the changes have on the timeline and the project budget.
If you employ a freelance writer or a writer who runs her own business, ensure that you have a contract in writing in place before you start the project. A contract not only establishes the work that the writer will do for the company - it will also provide guidelines for what to do in case the amount of work or hours exceeds what's stated in the contract.
The uncertainty principle
When I talk with people who are just getting into the technical communication field, no matter if they're getting into technical writing, online help creation, instructional design or Web design, I ask them if they're familiar with Star Trek. If they are, I tell them they need to incorporate their own Heisenberg compensator, the device that the Trek universe uses to compensate for the Heisenberg Uncertainty Principle when people beam from one place to another.
Uncertainty is part of the job when estimating documentation costs, and some answers only come from experience. As you continue to create estimates for stakeholders and provide the documentation that you and your team need during the development process, you'll gain the confidence of the company and its stakeholders, as well as peace of mind.
Eric Butow is a contract technical writer for Writing Assistance Inc. He also is an author of computer books, as well as an instructional developer and instructor for Education to Go and California State University, Sacramento.
Register or login for access to this item and much more
All Accounting Today content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access