RE: Refining My "Cutting Edge" Technical Writing Skills Post

[MList -at- chrysalis-its -dot- com]

eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com opined:

> But, if you need more time perhaps the situation is 4 weeks for a less
> complex situation with 3 "researching" and 1 "writing". With a more
> complex situation it may be 4 months but still with the 3 to 
> 1 ratio. Or,
> as John showed, a less complex item may take 50% learning and 
> 50% writing
> (1 day each).
> 
> If time is a fixed variable, then it's another matter all 
> together. We're
> back to my 'enough' scenario.

Going a little further with that, my experience of computer, 
communication and crypto product development is that quite 
often the total time for the project is a constant <g>, and 
that Customer Documentation is just *one* of the components 
that gets squeezed.

A situation that I've run into more than once is that the 
scope of the project changes partway through -- often after 
a big (project-driving, due to the pending big orders) customer 
has had a chance to play with the early prototype (hardware, 
software, or both). Perhaps they decide that that's not quite what 
they meant, or that (having seen how it works "in the flesh", 
they need some additional functionality to make it useful in 
their environment. However, because they have already made 
promises to THEIR customers, based on our original estimates, 
and because they are bigger than we are, we start finding ways 
to make the project satisfy them, without taking more time.
One possibility is that a bunch of functionality is left out, 
that was expected to be widely desired in the next release, 
but which is not important to the particular, driving 
customer.  Given that I had started my docs based on the 
original requirements and specs, my draft docs are now wrong, 
and I have wasted (for the purposes of the current project) 
precious days documenting things that won't be part of the 
upcoming release.

So, while the developers are scrambling to add/remove/modify 
the product's function at a time when they were supposed to 
be well past (don't laugh...) "code freeze", I am doing 
similar things to my documents. I'm taking out stuff, 
re-arranging other stuff, and putting in stuff that was 
never formally predicted. Not only that, but since everybody 
is so squeezed, the updates to the engineering docs that 
describe the revised function and design will likely be 
issued just after the product ships. Meanwhile, all the 
prototypes that QA/PV and your faithful author are working 
from are wrong-wrong-wrong. Rebuilding them needs to be fit 
into the newly-crunched schedule, so that PV will have something 
vaguely resembling product to test. I'll have my updated unit 
just about the day that I'm getting my completed docs signed off, 
so that they can go onto the "final" release-candidate software build.

But the deadline never budges.

I see a lot of people nodding in recognition of their 
job/situation descriptions.  :-)

Coping with that, and even enjoying the challenge is about 
the best form of "job security", don'tcha think?

/kevin

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -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.