Defining Your Tasks

[NetBrett Thorson <bmthorso -at- AVISTAINC -dot- COM>]

I am reading the "Managing Your Documentation Projects" book by Hackos.
Previously, we were in an ad hoc state for creating our documentation.
However, I am bringing our doc projects up to par with our very organized
software creation projects.

There is one thing that I don't understand so far.  I am looking at two
possible projects that we could use for a test bed.  The first project,
already has the software installed, the people are using it, and they know
what they want.

So that helps out a lot with the question, "What do you want from the
documentation?"

However, the other project I am testing this on is the deployment of
Microsoft Outlook internally.  I know what the product can do (e-mail,
calendars, etc.)  But how do I discover the tasks other people want to
perform.

I would first need to introduce them to the product,
Show them what it can do
Ask them what they would want to do with it.


Further more, I am wondering how you people write these documents without
even having a product made that you can show them.

So in the end, I guess what I am asking is how do we as tech writers
discover what the user wants to do with the system, before they know what
the system can do?

--Brett M. Thorson