Re: Estimating a project's scope-initial questions.

[ArtElser -at- AOL -dot- COM]

Raymond Chenier <rchenier -at- SYNAPSE -dot- NET> in a post on 15 Aug asked about how to
design a questionnaire for determining the scope of a documentation project.
The targets for the documentation are "a number of highly technical UNIX
based
software modules."

For each of the s/w modules, I'd ask what specific tasks the module would be
used for. Try to find out every task the user can do with the module, either
by itself, or in concert with other modules or applications. You'll need to
write instructions for accomplishing each task, or most of them.

Then, I'd ask for a list of every screen, fields on each screen, navigation
buttons, programming commands, and dialog boxes for each module. If you
provide reference documentation, you'll need to document most of these items.

You'll also have to ask questions to determine who the users of this
documentation are. Are they end users, programmers, system adminstrators?
This will make a difference in how you design the documentation.

I'd also ask for a listing of the goals of the documentation and training so
you can be sure to address these goals with your proposal. For example, if
the users are end users, and the goal is to get them quickly up to speed with
the modules, then you'll focus on task-oriented docs, perhaps with a quick
start guide. If the users are programmers, you'll focus on reference info,
perhaps adding a quick reference card showing command syntax and parameters.

Then, I'd ask the client to break the tasks and reference elements into
categories like short, average, and long in terms of how many pages it will
take to document an item in each category. For example, a simple task may
take a half page, an average task a page and a half, and a long task three
pages. Then find out how many items fall into each category.

With these numbers, you can come up with a total number of pages for the
documentation-yes, page count is important. If you are doing online
documentation, you can start with a page count and figure that each screen is
roughly a third of a page.

Now multiply the page count by the number of hours you think it will take you
to do each page. A rough industry average is between 5 and 7 hours a page.
Those hours include research, writing, editing, revising, project
management-everything it takes to get the page out the door, except graphics
and usability testing.

You'll have to estimate the number of graphics, so include that on our
questionnaire. Will you include usability testing? Add that in too. If you
are not sure the client wants usability testing, make your bid for the
project without that testing and add it to the end of the bid as an option,
with its cost. Even if the client things he or she wants usability testing,
it's a good idea to keep its cost separate so it has adequate visibility. It
might be the thing that can be easily cut to fit the project into the budget.
"I hate it when that happens."

Hope this helps. Sorry no one responded the first time. Guess we all thought
someone else would respond.

Art Elser
Comtech Services, Inc.
art -dot- elser -at- comtech-serv -dot- com

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-