Re: the document development process

["Marvin W. Miller" <Marvin_Miller -at- SEC -dot- SEL -dot- SONY -dot- COM>]

We use this concept here. A tech writer is assigned to a project almost from
the beginning. The writer works closely with the GUI team early in the project
and is often part of the QA process near the end of the project cycle.

If the product is difficult to document, it will be difficult to use. It
doesn't matter how well the manual is written. As a writer, you really are an
advocate for the end user. The sooner your involved, the better.



> There is a concept called concurrent engineering which embraces the
> fully functional team scenario (i.e., no outside help required
> and everyone collaborates and shares the workload so the project can
> be completed in the shortest amount of time with the highest end
> results).

> In such a scenario, a technical writer becomes part of the
> development team and is physically moved into their area. The
> writer becomes the key documentation person. Initially, the writer
> works with engineers to produce engineering specs which are
> later transformed into customer documentation. During some periods,
> the writer might be needed to help solder cables, run lab tests, or
> do other non-writing technical tasks which add to the writer's
> knowledge of the product.

> This is the ultimate form of cross-training and maximizing
> critical resources. However, it has had mixed results. In many
> cases, people are unwilling to let go of traditional roles and do not
> want to perform tasks outside of their perceived job
> description. Nonetheless, it has been successful in high tech companies.