TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
contributors.
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.
