Re: Help2

[Betsy Maaks <bmaaks -at- FRAME -dot- COM>]

At 14:29 8/7/95 EST4EDT, you wrote:
>I recently sent a message to the list about how technical writers get
>their information and what they are responsible for.  I appreciate the
>responses I received, but I think I need to clarify my question.  Here it
>goes.

>I am the Technical Publications Manager and I have seven years of
>experiance.  I work for a bar code scanner manufacturer.  The majority
>of my contacts are engineers.  There are five writers responsible for
>product documentation, systems (software) documentation,
>presentations, prorposals, data sheets, product catalogs, and any
>other miscellaneous documentation.

>Through the years, the Technical Publications Department has not
>been taken seriously or given much respect at all.  I can handle this.
>I think it goes with the territory.  I am attempting to make our
>department more a part of the product.  If a product currently comes to
>production.  We may not get a manual out until 500 or so units ship.
>This is unexceptable.  Because of this we created pre-installation
>manuals, preliminary data sheets, and product information
>summaries.  In my opinion, a bunch of paper that would not be
>needed if we just got the manual done on time to begin with.

>I know this sounds like complaining, but it is not.  Through years of
>frustration, I finally have the power to do something about it, and what
>I am asking for is ideas of how your product manual development fits
>in with your companies product development cycle?  Currently our
>product manual development is out of the loop.  I need to know just
>where to put it in the loop.

>---------------------------------------------------------------------------
-----
> -----
>William MacLeod                                 wbmacle -at- accusort -dot- attmail -dot- com
>Technical Publications Manager           +1 215.721.5093
>Accu-Sort Systems

>The opinions in this message are my own
>---------------------------------------------------------------------------
-----
> ----


William,

I worked for a Bill MacLeod in documentation...are you the same Bill I
worked for??? Probably not, or you would not ask this question because, when
I worked for Bill, we had Product Introduction Teams (PITs), which were made
up of Engineering, Marketing, Sales, Documentation, Customer Service,
Training, etc. One rep from each department who was assigned to be "lead"
for their department for the product. The PIT met weekly to discuss
development, needs, glitches, resources, timing, etc.

Basically Engineering drove the time schedule, but we all pitched in.
Engineering assigned developers to the project, and we in Documentation knew
who was assigned. We would keep track of development in the weekly PIT
meetings, but also 1-on-1 with the assigned engineers. We in Documentation
developed a suite of documents that we believed we needed to either update
or create, came up with a time line for development, reviews and final product.

If our schedule showed that there was more writing than person hours
available to do the writing, we either (a) looked at assigning another doc
writer to the project, or (b) worked with the PIT members to determine the
suite of documents that would be available for shipping, and those that
could be shipped when ready (prioritize with the group--not on your own!).

The rule is: the earlier we got involved in the design of the product, the
earlier we could determine the scope of the work (docs to update/create),
and then we started organizing and researching. If there were OEM products
involved, we scrounged for manufacturer's manuals, or even called the Doc.
Department, as was the case when we were using a beta version of an OEM
product.

Another way to be involved early is to participate in the QA effort. There
was always testing performed on the product IN-HOUSE before it was shipped
for field trial at the customer's site. I always volunteered for testing
because I saw the product _as a whole, not just pieces from each engineer_.
This clarified screen menus, and functions that maybe had been changed since
I last talked with the engineers. I could usually print the screens while
testing, map out some notes, and use any preliminary documentation that I
had written. I also made comments to clarify the acceptance test plan that
we followed for QA, but that would be given to the customer for final
acceptance after the field trial.

Another area that helped the documentation was the fact that the preliminary
documents were shipped to the field trial and used by customers who would
then become familiar with the product. In one activity, the documents were
reviewed and customers trained.

This entire process took from 6-9 months, for a product that we installed
for the customer. I can understand that this process may not work for other
types of firms, like ones that ship product from the shelf. Think about what
you can use. If you would like more details, email me directly.

Hope this helps!

****************************************************************
    Betsy Maaks          +         Frame Technology Corp.
   312-266-3208          +         Advanced Products
 bmaaks -at- frame -dot- com        +         441 W. Huron Street
                         +         Chicago, IL  60610

****************************************************************