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.
Certainly, CIDs (you could also call them KIDS with a hard "c") are a
common complaint by contractors and noncontractors alike. And certainly,
if you don't deal with it directly, it's a lose/lose situation. As a
result, you no longer want to work (or work is not a joy) with the
people and feel a bit like a victim. They feel confused and usually will
sense your anger.
I describe these outcomes just to underscore why you must deal with this
directly and early; although, perhaps your reflex is to be nice about
it, cover up, and go along. I assure you that serious professionals in
both tech writing and programming don't survive long without learning
how to deal directly with these sorts of customers.
You must describe milestones, cutoff dates, and deliverables in your
contract. If, later, you decide to cut them some slack, it will be up to
you and whether you believe that you can cope with it. You also must
describe the impact on the customer for not meeting their deliverables.
The impact can be any number of things. It could push your deliverable
dates out. It could cause you to charge more. It could cause you to add
people to the project, etc, etc. There are many approaches. You might
even ask how their programmer or QA teams handle delays. How are they
accomodated? This approach may shift their view of you and your
requirements to something they readily understand.
You are wise to want to spell this out early in the process when the
issues are not charged with emotion. I do a lot of planning and
orientation for my customers for new projects, and it never fails that
it creates satisfaction on both ends and a more pleasant experience
overall.
-- Nancy Hickman
author of "Building Windows 95 Help"
consulting in Help and advanced assistance for applications
Robin M. Allen wrote:
>
> Hi:
>
> This question is for all of you seasoned contractors out there. I'm
> looking for 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'm not talking about software development delays, or a fire at that
> wipes out the source code. I'm talking about information they said they
> would give you, they know you need it, you know they have it, and they
> just won't get it to you.
>
> A consultant friend advised me to escalate the pay rate for each delay
> and I've mitigated the problem with one client by charging for
> non-productive hours. But I want to make this part of my agreement up
> front.
>
> How do you handle this situation?
>
> Thanks:Robin Allen
> robin -dot- m -dot- allen -at- worldnet -dot- att -dot- net
>
> 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
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