Re: Documenting A Moving Target

[Kent Newton <KentN -at- METRIX-INC -dot- COM>]

I emailed my response directly to Karen Qwynn, but because of the public
response, I thought I'd add my two cents to the public forum.

>Eric Ray wrote:

>You'll never get past the moving target problem, but you need to put
>the responsibility for keeping you adequately informed on your
>developers (or their management, if necessary).

Like reporters, technical writers can play two roles.  We can be like the
White House press corps who follows the Press Secretary waiting to be fed
official pronouncements that we then report.   These reporters only get
the information that the White House wants them to get.  Or we can be
investigative reporters who seek out the information that the White House
"forgets" to pass out or would rather keep secret.  In a perfect world,
developers (and the White House)  would always and completely disclose
the information they have, but this isn't a perfect world and they don't.
 I often think of myself as a user advocate and feel it is my job to find
as much about my product as I can, and then pass that on to the user.

My strategy is pretty much the same as had been suggested by many others.
 Here's the suggestions I sent to Karen (modified slightly for mass
consumption):

(1)  If no one has been assigned the responsibility to notify you of
changes, _you_ must take charge and assign that job to someone.  Pick
people high up in the development cycle (Product Manager and Development
Manager, for example)

(2)  Let that person know what is expected, and then pester the bejeezus
out of him or her until it sinks in.  Some information to ask for:

 -- what projects are being developed,
 -- who is involved with developing each project,
 -- what is the time line was for each project, and
 -- what specifications are available (paper or computer based),

I'm sure there is more information you could ask for.  Think about it for
a while.

(3) Each week, sit down with your appointed representative to determine
the progress of each project, to identify any changes that are being
made, and so on.

(4) Don't rely on your appointed representative.  Once you know who is
programming what, approach those programmers and implore (read: pester)
them to keep you informed of their progress.

(5) Play tag with all these people until you know what is going on.  With
luck, you'll be able to train them to keep you informed on their own just
to get you off of their backs.

(6) Schedule your writing around those projects that are early in the
development cycle.  Adjust your schedule and outline weekly as you get
updates.  It's time consuming, but I found it works better than waiting
for the developers to notify on their own.

(7) Near the end of the development cycle, pick a date, tell everyone
that any changes after that will not be included in the documentation,
and then include an Addundum with any changes made after publication.
 Inelegant, but it works.

Kent Newton
Senior Technical Writer
Metrix, Inc.
kentn -at- metrix-inc -dot- com