New things new ways, more about scenario (1)

Subject: New things new ways, more about scenario (1)
From: JohnBrin <johnbrin -at- AOL -dot- COM>
Date: Wed, 6 Jul 1994 16:42:07 -0400

Several day ago, I described three scenarios related to doing new things
new ways. This message expands on the first of those scenarios, a copy of
which follows:
(1) Consider this scenario: Engineering begins development of a new
product. About two months into the project, tech pubs gets involved.
The project continues toward conclusion, and tech pubs works overtime
to incorporate last-minute changes. About that time, training
development begins. The training developers use the same source
information as did the publications people. The pubs go out with the
initial deliveries or shortly thereafter. Training becomes available
some time after initial deliveries. I've seen such a scenario hundred
of times. Are there any problems with it?

How about duplication of effort? How about differing views of the
same things? Could there be contradictions?
Consider another scenario:

A cross-functional team (engineering, marketing, tech pubs, training, tech
support, and customers) begins development of a new product. This team
reaches preliminary agreement on the content of the product and the
support it will receive.

The tech pubs and training people agree to take the lead in developing the
project documentation, including documents that will be delivered to
customers with the product. This doesn't necessarily mean that they will
write all documents, but that they will oversee the documentation process.

As product development continues, the team, the product, and the project
benefit from team synergy--two or more heads are always better than one. A
team is far more likely to pick the best solutions than are individual

The tech pubs and training developers benefit from a common vision. They
don't duplicate each other's work, and the aids they develop for user
performance complement each other. The examples used to inform, instruct,
and aid practice are the same examples. Because all team members share
common goals, the product is likely to require less documentation and
training than it would otherwise.

The product might turn out to have online help that is actually helpful.

Because everyone involved in the project come to better understand the
needs and concerns of each other, subsequent development programs are more
efficient and effective. Customers' perception of product quality,
usefulness, and value is enhanced, and the enterprise prospers.
I encourage comments, especially from anyone who is participating in a
similar process.

John Brinegar
Phoenix, AZ, U.S.A.

Previous by Author: New things new ways--Follow up
Next by Author: Research on value of tech documentation
Previous by Thread: Re: How do You use the WWW?
Next by Thread: Re: Mosaic

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

Sponsored Ads