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:Taking on a contract? From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Kevin McGowan <thatguy_80 -at- hotmail -dot- com> Date:Wed, 25 Jan 2006 09:25:06 -0500
Kevin McGowan wondered: <<I'm going to meet with the reps from this
company tonight, and am looking for a bit of advice as to what specific
questions to ask. Basically, they are a small company here in Ottawa,
about 14 people. They've all been doing the writing (tech manuals,
marketing blurbs, help files, etc). To quote my friend there: "we're
tired of doing the writing because we're tripping all over each other."
At the moment, they are creating a lot of XML files and they apparently
want to turn that source into nice looking PDF files (probably with
Word).>>
The biggest and most important question is to get a good description of
their development process: how things are designed and created. This
tells you whether you're aiming at a constantly moving target with no
way to guess where it's moved, whether the target is changing but at
least they'll tell you, or whether they actually understand the concept
of a blueprint. <g> This tells you how much to pad your estimate and
how much grief to expect.
Next, you need to pin them down on the details of what you'll be
documenting. Those details form the basis for your contract, and any
changes to those details are billed at your usual hourly rate--or
possibly a higher rate if this leads to insane deadlines. (Define
insane, of course. In software development, it's kinda subjective and
relative. <g>) This protects you against feature creep.
Pin down the review and revision process. My usual contract says "you
get one review and one free revision in response to that review;
everything after that is on the meter". That's an overly simplistic
version of a longer and more detailed discussion that comes down to the
following: "I'm prepared to do a reasonable number of revisions, but if
you guys can't get your shit together and do the job right, you'll pay
for the privelege of making me do it dozens of times".
Speaking of which, make sure there's a "due diligence" clause: you'll
do your best to get the facts right, but you're not the expert--they're
the experts, and must take responsibility for approving what you've
done. In short, "cover your asciii". If it's a moderately long job, get
payments at frequent intervals, and add a clause such as the following:
"payment represents approval of all work submitted to that point".
The rest is all relatively obvious: discuss tools, deliverables,
milestones, deadlines, and payment dates. I find the easiest way to
come up with this list is to roleplay the process: imagine myself going
through the entire documentation process, from the first day on the job
to the final celebratory beer, and make notes of everything that
happens along the way. If you don't know exact details of those
happenings, ask to find out.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
