Re: how do you....

[Karla McMaster <mcmaster%pcmail -dot- cti-pet -dot- com -at- CTI-PET -dot- COM>]

Regarding Glen Accardo's comments on estimating schedules and the trouble with
creeping featurism...

This comment really hit home, because I have never worked in a place that was
any different, i.e., the small companies I've worked for have all been run by
developers, not marketers. (That may not be what the marketing department
thought, but it was the actuality.) Therefore, there never were any specs,
unless I wrote them. When I have been asked for an estimate, I say I need
specifications. When they can't give me any (as I say, I've never gotten any),
I say I'll be done before the product is--and I always have been. (Luckily,
small companies has meant I haven't been doing any four-color presswork--
turnaround time for printing hasn't been more than a week, generally.)

The key to keeping up with what's going on, for me, has been establishing close
working relationships with the developers. Similar physical location helps,
especially in a cubicle environment--you may overhear the beginning of a
conversation about changes that are being made, and you can butt in. I make it
a point to "visit" with developers regularly, and _ask_ what they're up to, so
that I may find out changes before they blindside me when I think I'm done. I
try to run the software, if applicable, directly off the development stuff, if
they'll let me. This way, if changes are visible, I can note them myself.

As for Glen's question about creeping features messing up your manual
organization, I just figure that's inevitable. Part of the job, in my
experience, is being flexible enough to make last-minute adjustments (including
reworking chapter organization). That's why I don't think I could do the job
without a first-class publishing system, which automatically takes care of a
lot of the last-minute things required for publishing, such as the table of
contents and index.

What may be most frustrating about creeping features, though, is that they make
the product look cobbled together. This is always obvious in the documentation,
perhaps more so than in the product itself. And it's tough to take pride in
your own work if it's not the neat package you originally envisioned. But the
writer can't make a funky product look good, no matter how great the writer is.

In any case, this discussion has left me curious about the experience of
working in a place where schedules are real. I thought they were one of those
unattainable goals...

Karla McMaster, technical writer
CTI-PET Systems, Inc., Knoxville, TN
mcmaster -at- cti-pet -dot- com