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.
Subject:-No Subject- From:Barry West <Barry_West -dot- S2K -at- S2KEXT -dot- S2K -dot- COM> Date:Mon, 8 May 1995 11:59:40 EDT
>I've a question for all you experienced contract writers. Do you have
>any advice on what to include when preparing a contract? Are there any
>guidelines or checklists to follow? The tax thread and other comments
>related to how to deal with setting rates have been valuable, so far.
One thing you should stick in your contract, if you're fix-pricing, is a
statement that limits the number of times a draft can be reviewed without an
additional cost. I have been in situations were the project people just won't
stop marking the thing up. For example, I was contracted to write a doc once
for which the project people and marketing people couldn't decide on the
presentation of certain things. I would send it in with edits incorporated and
get it back with markups that changed the edits I just incorporated. Even
though I questioned it, the response was always, "just put in the changes." It
turned put that the Project Leader was alternating who she sent the draft to
for review, but didn't bother t find out if the two groups were in agreement.
So, both groups just kept marking it up, until I finally called and said no
more. This happens more than you might think.
Also, particularly in software writing, you should include a clause that allows
you to charge extra at a specific hourly rate for added functionality. Very
often, for various reasons, functions are added to software applications that
were not included as part of your quote. In fact, sometimes you may be asked to
quote on a project with only a spec to go by (vaporware). I had one project
where the project people at one point decided not to include a help function
because they felt they didn't have time to get it done (marketing decision).
But then they decided to add it. After I had written it up, they decided to
take it out. Finally, they wanted it back in. This created a great deal of work
because the function affected multiple parts of the manual, and they made their
final decision after the book was all laid out. I always allow a certain amount
of project flexibility as a matter of good PR, but not a lot. Common sense
would say that you should be paid more in certain circumstances, but when it
comes to money, common sense does not apply. Do yourself a favor and put it in