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.
Bonnie Granat wrote: <<A prospective client (the same one I wrote about
some weeks ago) and I are in the process creating a Statement of Work
for the first part of the project. This first part consists of a User
Guide that contains both end-user and administrator information. While
I have seen the application, I have not seen it yet in actual use.>>
Cue scary background music... <g>
<<The client will be coming to my home office to train me for 8 hours
and after that I will begin work. My problem is this: the client has
estimated the time for writing to be 120 hours, and I cannot tell at
this point how many hours will be required.>>
You informed the client that the estimates seemed reasonable but that
you can't tell for sure without actually seeing the program. That's
reasonable, and it seems like they've accepted your suggestion, which
is a good sign. If you can get the client to provide you with a
functional specifications document of some sort (i.e., a list of
features and the number of interface widgets such as menu choices,
fields, utilities, etc. used to implement them), you can come up with a
better estimate.
If they don't have any such planning document, add in a ton of padding
to account for "feature creep": people who work without a plan are a
nightmare to work with. I fired a client recently because they were
largely "making it up as they went along", and I have too much other
work to put up with that kind of amateurish crap. Life's too short, and
all that. (Before anyone asks, "too late: I already passed the client
on to a colleague with more patience than I have, and everyone loves
each other. Sorry!")
I recommend adding a clause to the contract that states something like
the following: "During the training session, we will develop a complete
list of all menus and dialogs etc. etc. etc. that must be documented,
and the client will sign the list to indicate that this constitutes the
***full scope of the work***. Within a couple days after creating this
list, I will come up with a revised estimate of time requirements.
Anything added to the interface after this list has been approved will
be billed at the following rate... [details]."
Also make sure to find out how much access you'll have to the
developers and to get this in writing; the less access you have, the
more you will need to pad your time estimates to account for research
and chasing down "people who know".
--Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
COMPONENTONE DOC-TO-HELP 7 PROFESSIONAL: From a single set of Word documents, create online Help and printed documentation. New version offers yearly subscription service, Natural Search, Modular TOC Utility, Image Map Editor, Theme Designer, Context String Editor, plus more. http://www.componentone.com/doctohelp .
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.