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: Need input From:Andrew Plato <intrepid_es -at- YAHOO -dot- COM> Date:Sun, 9 May 1999 13:27:14 -0700
I feel your pain Sharon. I have clients that pull this crap all the time.
Even the good ones. I usually have the same answer: time and money.
"Time and money can solve anything. However, since time is running out as is
money, we must find a compromise. Here are my suggestions for solving this
I think they have a valid point about having a doc ready at any moment. With
many of my clients, prior to FCS, they'll often need beta copies or copies to
give to big customers. Naturally, they also want to show them that there is
documentation being done.
So I agree with them that there should always be a doc ready to go out the door
- even if it is incomplete. With my clients, when deadlines are close, I start
doing drops every few days of the material. If they want a current version,
there is always one that, at worst, is a few days old. You might want to start
generating PDFs of the docs every few days, or at meaningful intervals.
If it is taking a day or more to publish a doc, you need to find a way to
shorten the turn around time. If not for this project then for the next. I am
doing a 1000+ page doc set with one other writer for a client right now . We
can make a drop in about an hour. Our docs are all in Word and we do PDFs as
well. It is important to have an established build procedure.
If you are both off-site, this exacerbates your problems 100 fold. This is why
I don't like to do off-site projects. Also, by not having a designated "owner"
of the docs, you are making your work about 100 times more difficult.
I'm sorry but it is impossible to have multiple writers communally owning a doc
set. I have never, not once, not even for a fraction of a second seen two or
more writers who could effectively manage a large doc set together. Two or more
people can NEVER agree on how to do things. There is always dissention and you
eat up 1000s of hours debating when you should be writing. Large doc sets can
only be effectively managed when one person has complete, totalitarian control
over the document. The owner is responsible for checking everything in, doing
builds, ensuring consistency, etc. All other writers should deliver their
material to the owner for integration.
As for the cost problem. You should do a cost-benefit analysis for the client
demonstrating different options and events and how that effects cost.
Sometimes, the best solution for docs, is to wait until a few months or even
weeks before the product is done, and then do all the docs in one, grand sweep.
Dribbling along watching and trying to respond to every engineering machination
can cause you to rack up 1000s of hours that are all wasted. Yeah, you might
have a better insight into the development - but is it really useful to know
how many times they have gone back and forth on some issue? Does that
information *really* help you when writing the docs? No, it doesn't.
I have advised many of my clients to wait until they have the design settled
before starting the documentation. If they have redesigned the product multiple
times, you should not have been there until the last design. There was no need
for you to being doing documentation on designs that did not stick. That was
all wasted time. You should make that clear in your cost-benefit analysis.
As a consultant, sometimes you have to meet the client's needs no matter how
ridiculous. A professionally worded, "solution-focused" email to your client
should ease the tension. Give them a list of alternatives. Mostly, make sure
to give them honest solutions to everything they are asking.
I don't know if any of this helps you now. You might be to the point where you
just have to slam out product and piece it all together later.
President / Principal Consultant
Anitian Consulting, Inc.
--- Sharon Burton-Hardin <sharonburton -at- EMAIL -dot- MSN -dot- COM> wrote:
> I have a client that in the past has been very good. This project, however
> has been hell. No features list, no design doc, no nothing. It is going to
> work just like the previous version except it will be different. They were
> supposed to go beta in November. They finally went beta in March, after 4
> redesigns from Jan to March. They hope to ship full version in 10 days - of
> course, they are done with some parts of the program yet, making it a little
> tougher to document. Needless to say, the docs are very inaccurate but we -
> the other writer and I - are struggling to catch up and get it back on
> My questions are the following:
> 1. They are very unhappy with the cost of the docs at this point and simply
> don't want to see that redesigning multiple times and no specs have caused
> this. Any input into helping them get this? I have explained and explained
> but to no avail.
> 2. They want the Framemaker chapters, as they are finished, checked into
> Source Safe with the ability to print and send out a manual at any time.
> Both writers work off site and may not be included in the loop on this
> release pattern. The client wants to have the manual ready to PDF at any
> moment. I don't seem to be getting across that releasing is going to take a
> day to generate/update, etc., before it is in shape for a customer to see -
> page numbering, toc, index, chapter numbers all that. Their point of view is
> that code can be built at any moment and sent out, if needed. Docs should be
> as well. With 2 writer working on separate parts of the same manual, how has
> anyone else managed this? Is what they want possible? How do you manage
> things like xrefs to other chapters? As far as I can see, even if I get a
> copy of the chapters when they are checked in and use those to make my
> xrefs, I can't make sure that it is all going to work when I check my parts
> in... Am I not seeing something? I keep telling them that one person has to
> own the book and we are simply not at the point where this can happen... But
> I want them to have what they want...
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com