re: At what point do you include the Information Plan?

Subject: re: At what point do you include the Information Plan?
From: "Christensen, Kent" <lkchris -at- sandia -dot- gov>
To: "'TECHWR-L'" <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM>
Date: Tue, 12 Sep 2000 08:49:29 -0600

Cathy De Rubeis had some questions ...

re: Do you think the Information plan should be part of a "frozen" Product
Requirements document?

This sounds like a pretty good way to go. You could be in a situation where
you never hear from the developers until they're finished and they just hand
you the software and tell you to write the manual. "Frozen" can become a
relative term, however, should, for example, your attempts to describe a
procedure fail ... which could mean the user interface needs redevelopment.

re: Is there enough information in a Product Requirements document to
develop an Information Plan?

This is your call, of course. Given the sophistication at your firm
evidenced just by the fact you're doing this planning, I'd say you're well
on the way to what you need. Any experience there from previous projects?
Seems like you just need to ask for what you need.

re: Is it the norm for Design documents to be so extensive in documenting
how a procedure works?

Funny question. I'd think there could never be too much, but some
accountant may disagree. This of course should not necessarily be a
prototype for overwhelming the end user with too much detail in the user
manual.

re: Where does the work of the developer end and the job of the technical
writer begin?

Given a well operating team, you'll never know. Developers will want to see
your manual. This is all good.

re: Do you think introducing an Information Plan after the Design documents
are completed is too late in the process?

It certainly could be. Again, you're well ahead of many firms just by the
fact you're doing this, but you could run into "political" problems around
the term "frozen." Just thinking theoretically, it seems pretty unlikely
that the documents could come out simultaneously, but it would be good if it
were close. Can you be on distribution for rough drafts of the Design
documents? Sit in on the review meetings? Hard to see how eagerness to
understand and to get it done early could be seen negatively unless you're a
too-relentless pest or something!

Again, while this is your "first technical writing job," I suspect it's not
the first time your firm has used these procedures. Can you review some
"lessons learned" analyses regarding how these procedures worked in the
past? Unless your approach appears predetermined negative, I suspect your
project manager may appreciate the request and your desire to understand the
big picture.

I think you need to be sure you can use the product as well as any
sophisticated end user at some point before you've finished the manual.
(Obviously) You don't need to understand all the product design details
(but it doesn't hurt) ... rather, you need to have confidence you can
describe use of the product in your manual in a way that your tech writing
education assures you will work for the end user and concurrently in a way
you can justify or explain to the rest of your team. Some reference to
previously successful manuals from your firm will likely be good, too.
Given the apparent planning of your project manager to get you involved
early and often and your clear desire to learn and do the right thing, I'd
venture you're well on your way to succeeding.





Previous by Author: Re: the world's most frequently read instructions
Next by Author: re: Linking to graphics: why, why not?
Previous by Thread: Re: At what point do you include the Information Plan?
Next by Thread: RE: At what point do you include the Information Plan?


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads