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:Re: Contractor Question -- Customer-Induced Delays From:JIMCHEVAL -at- AOL -dot- COM Date:Sat, 7 Jun 1997 12:29:36 -0400
In a message dated 97-06-07 10:48:18 EDT, robin -dot- m -dot- allen -at- worldnet -dot- att -dot- net
(Robin M. Allen) writes:
<< some language to put in my contract regarding
"customer-induced delays." You know -- your scheduled gets blown away
because the client is non-responsive and then at the 11th hour, *you*
are scrambling to meet *their* deadline.
>>
I always loved - but have never dared to use - the phrase I saw in one shop
when I was a programmer:
"A lack of planning on your part does not constitute an emergency on my
part."
Unfortunately, when you're on staff, it often DOES.
For contractors, a lot depends on your existing relationship with the client.
If you feel you can trust the client to acknowledge the cause of the delays,
you may only need general language that specifies that "Certain assumptions
have been made in arriving at this estimate. If these are not met and delays
result, additional hours will be billed at $___".
If not, you probably need to define a certain number of dependancies in the
contract, with clear-cut language about what will happen if each of these is
not met. Usually the latter is simply an hourly rate for any work over the
estimated time.
My last client also built in review intervals so that we could both track how
on-track the whole thing was, and discuss any overruns. I think that's a
good approach.
In a worst-case scenario, you might really have to list detailled
dependancies, with the specific time impact for each. But if you have to get
to that level of detail, it's probably not a great relationship anyway.
Jim C.
Los Angeles
=======================================================
Visit Chez Jim: Jim Chevallier's Home Page - http://www.gis.net/~jimcheval
=======================================================
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
