Estimating documentation costs for a project 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 you can perform for a particular project because each project and each writer are different. For example, one or more of the following situations may apply to you:
You are a freelance or contract writer who telecommutes most of the time, and you don’t work on a regular 8-to-5 schedule.
You work on site as a full-time employee, but you may or may not have a team of other writers working with you.
You are 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.
You’re working on usability studies and testing as part of project development.
No matter what situation you find yourself in, it’s always difficult to figure out where to start. The answer is easy: start with you.
Do Your Homework
When your project manager asks you for estimates and deadlines, only you know how productive you are. If you’re not aware of how productive you are, remember back to past projects and put together some simple metrics to give yourself an idea of what you can do. For example, in your last project you may have been able to write and edit content on one 8½ 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 to write so many words (or pages).
If you’re a freelancer or you have your own business, you also need to find out how much to charge. To provide an accurate quote, you need to do your homework. For example, look at other companies that provide similar services. You can also research salary surveys online, such as the technical communicator contractor survey produced by the Society for Technical Communication. Mailing lists and newsgroups such as the TECHWR-L mailing list for technical communicators are also valuable resources.
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 bring. For example, in a software product you may have two buttons. Button A brings up 4 choices, and Button B brings up 5 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 hard to understate the importance of keeping in close contact with the development team if at all possible so you can update your documentation accordingly, instead of having your customers and/or stakeholders pointing out the problem.
Document Your Documentation
As you create a checklist of everything you need, be sure to share this checklist with your project team and/or manager so everyone understands what features are supposed to be added. If there are any additions, be sure to keep a copy of your own checklist and, if necessary, distribute that checklist to the other project team members and be sure everyone understands what changes are being made not only to the project list, but also the effects those changes will have on the timeline and the project budget.
If you’re a freelancer or you run your own business, you need to have a contract in writing that establishes all the work you will do for the company. If your client decides to add more work on your plate that’s beyond the scope of the contract, be sure the contract states that you will work on a per-hour basis at your hourly rate.
No matter if you work on a project team or you work independently, always be sure to add markup. Markup is additional time and costs on top of your original estimate to ensure that any delays in the development process will be compensated. For example, if a key software engineer on the project team goes on vacation, you’ll need to compensate for that in terms of time and/or money.
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, and/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 Star 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 the fountain of experience. As you continue to create estimates for clients and provide the documentation you and your team need to protect yourself and the development process, you’ll gain the confidence of the company and its stakeholders as well as peace of mind.
About Writing Assistance, Inc.
Eric Butow is a contract technical writer for Writing Assistance (www.writingassist.com).
Writing Assistance, Inc. specializes in contract technical writing, copy writing, web content specialists and training developers and is dedicated to the proper placement of contract writers nationwide.
