TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Beth Kane is just about <<... to get my first independent contract>>
Congrats! I'm still a wage slave and loving it, but most of my friends love
the contractor's life. One thing that will suddenly change is that whereas
you used to be working to a familiar, well-defined standard, now you're at
the whim of someone with entirely different expectations. That being the
case, make sure you provide writing samples _early_ in the process and get
the client to review, revise,and approve them; without that agreement on
what you're supposed to produce, you could end up documenting the whole
thing and discovering only at the end that they don't like your style or
presentation (e.g., they might love passive voice) and that it all has to be
redone. Guess who has to rewrite everything for free if they don't like what
you've done? Solve that problem once at the beginning, and never worry about
it again (ideally, of course).
<<Can someone give me suggestions on how to come up with a fairly accurate
estimate?>>
A few important tips: If possible, try to get a good look at the product
you're documenting, and bid based on the number of fields, not just the
number of dialog boxes. It's easy for developers and their managers to
forget that a dialog box might have anywhere from 1 to 100 things that you
need to document, and that each field (for example) takes a certain amount
of time to document. Based on your experience as a wage slave, you should be
able to come up with a good ballpark idea of your productivity on
documenting a single field or button or whatever; multiply this by the
number of fields you expect, and make sure that this number is clearly
indicated in the contract, with a clause that says "oh yeah, and $500 for
every field after the first 100". <g> Of course, this assumes perfect access
to completely cooperative developers who are working to a well defined plan.
In reality:
<<I've heard many people say you should figure how long it will take, then
double that amount (and maybe add even more time).>>
That's a reasonable fudge factor, but you can be more precise than that.
Assume that for each field (or whatever) that you document, you'll have to
spend a certain amount of time finding and interrogating the developer
responsible for that field. (Depending on your familiarity with the product
and how much access to the developers the manager will guarantee you,
estimate how much time you'll spend defining, asking, and resolving your
questions. And get the manager to guarantee access to the developers as part
of the contract. You may not be able to hold them to that clause later, but
at least you can then point out that you're honoring your part of the deal,
and they're not, and you can't be expected to make it all up by yourself.)
Add that to the estimate as a fudge factor for each field. Also state
clearly that you'll do two revisions for the base fee: no more, no less. The
first revision is the developer's review, and the second revision is the
manager's signoff on the completed docs for that field. In reality, you'll
probably revise more often than that, but this should appear as a penalty
clause, without calling it anything that offensive: "This estimate includes
the two reviews I just defined; each additional revision will cost $5000 per
revision." <g> (One can always dream!) Make sure that you have a "they
changed the entire interface and didn't tell me" clause, with a high-enough
billing rate for updating things that they get the message that your time is
worth taking into account, but don't scare them off with ridiculous
surcharges (like the $5000 I facetiously used as an example).
There will obviously be deadlines and dependencies involved. Make sure you
discuss these with the client, and make it clear that you can't document
something that is incomplete. If they expect you to meet certain deadlines,
clearly specify that the deadlines require deliver of something stable X
weeks before the deadline. You can't meet a deadline if the product isn't
ready to document. Keep the lines of communication open so that the manager
never receives any surprises; the time for the manager to hear that you
never received what you're expected to document is when the delivery
deadline arrives, not when your part (the docs) is due.
<<whether development is complete or ongoing>>
If you get any sense that the design is in flux, and that you'll be
constantly revising, make sure that you come to some kind of agreement with
the manager that you'll only document something once the interface is
frozen, and that they'll compensate you for any subsequent changes.
Alternatively, indicate that anything that changes once it's been documented
costs extra, and that you'll charge by the hour to find unannounced changes
if they can't come up with some way of informing you of what's changed; do
you really want to search through 200 dialog boxes every week to see whether
they've changed one crucial line in the interface? Sure, they won't like
this, but it's abuse of you and your time to expect you to document the same
thing 20 times for free and spend the rest of your time hoping you can spot
random changes in a million lines of interface code.
<<whether troubleshooting docs need to be written, or error message
explanations...what else?>>
"What else" depends on the client. Do they want tutorials? Marketing
materials? Make it clear to them that if they don't specify it in the
contract, you're not doing it for free. If they're uncertain about what
materials they need, propose appropriate materials to them, and when they
agree, put it in writing.
Obviously, all of these "cover your ass" suggestions require considerable
diplomacy and tact; state your case quietly, calmly, and professionally, and
the odds are good that you'll get the terms accepted. One other note, based
on some horror stories I've heard from colleagues here and elsewhere: make
sure that the person you're contracting with has authority to sign the
contract and enforce its terms on behalf of the company. Occasionally, you
might deal with a project leader who doesn't have authority to do management
signoffs higher up the food chain, and if that's the case, you'll need to be
aware of this and plan accordingly (e.g., add another review and revision
cycle to the bill, get the person who actually approves your invoice to
approve the contract too).
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"In seeking wisdom, the first step is silence, the second listening, the
third remembering, the fourth practicing, the fifth -- teaching
others."--Ibn Gabirol, poet and philosopher (c. 1022-1058)
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
