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:SUMMARY-Trng & Manuals at product roll out. From:Tim Lewis <TLewis123 -at- AOL -dot- COM> Date:Fri, 17 Nov 1995 17:12:45 -0500
Howdy techwhirlers
Thank you to the 18 people who replied to my posting about having training,
manuals, and video ready at product roll out. Some people gave me some very
good examples of projects that they have worked on. The original questions
are copied at the end of this summary. You gave me a lot to think about and I
am going to take action on your suggestions. In fact, I wrote a memo to the
Training Center Manager and Technical Publications Supervisor suggesting that
we work together to obtain information to do our jobs collectively on future
products.
SUMMARY-----
The majority of replies said the same thing.(Most replies assumed that my
product is software, which is true for many of our products but we also make
hardware.) They said that it is important to get involved with the project as
soon as possible and obtain information from developers, marketing,
programmers, trainers, and gather specification sheets and other documents.
Be involved with development meetings early on. Kendal Scott said, *There's
simply no substitute for understanding the thinking behind the work as it
happens; trying to reconstruct it after the fact is feasible, but it
eliminates much of the opportunity to put yourself in the customer's shoes,
which is a crucial element in technical communication in any medium.* Some
suggested develping a good rapport with the engineers.
Most people said to write an outline-leaving out the details-and have the
people approve it. Start with what you think is true and ask the SMEs to
verify it. As the product development moves along, details can be added as
they become known. You should try to get a beta version and work with it
yourself. Sue Heim said, *Obtaining info is the hardest part of the job --
but if everyone cooperates in a team sort of way, you (well, OK, I) can
usually get the job done in time.* Kin Fawcet suggested, *. . .find other
products similar to the one under development. Then we grab info from the
older manuals, paste it into the outline, and try and find engineers who'll
verify whether the info is still correct.* Some replies suggested that I
learn the product myself because *. . . you cannot write about what you don't
know.*
Several said that it is important to educate the client on the video
production (or tech writing) process and explain that any changes after
certain dates/steps would jeopardize the target date. For contractors, this
means writing this into the contract. They suggested using a flow chart to
establish goals. A couple of people suggested being a consultant and educate
the client of your needs without going into detail. i.e. Explain the video
production steps just as you would for tech pubs. You would state, as Robert
Plamondon said, *that you will need extensive support from engineering in a
particular time frame, extensive support from marketing in a particular time
frame, a product that matches the released product at a particular time
frame, etc.* A couple people also said that you should not become a *team
member* because they often get jerked around. It is better to remain a
consultant.
Toni Pieri takes the *1000 pound gorilla approach to gathering information
from SMEs.* He said, *. . . I tell them that I have a job to do, that I
consider it part of their job to help me with my job and, above all, God help
them if they don't help me. I never hesitate to go up the management line if
I feel that I'm not getting the cooperation I need and I make sure that
everyone is aware of it. Needless to say, I'm not the most popular guy in the
world. But, I turn out a good product that is usually on time and that's
what I get paid for.*
Other things that you can do is listen closely to the grapevine, attend
meetings, and get management support of your efforts. You need to understand
something about the technology before you begin the project.
All the replies are very helpful. Thanks again. Hope this is not too long for
a summary. 8-)
TLewis123 -at- aol -dot- com
Tim Lewis
ORIGINAL QUESTIONS--------
1. How do you gather enough information to create manuals and/or training
materials so that it can be released with the product?
2. Do you start writing what you know, as soon as you learn about the
project, perhaps from technical specification sheets, or interviews with
experts?
3. Are you involved in the project early on?
4. Should I educate my *future* clients about the video production process
and insist that technical experts be available to give me the information
that I need? Should I be part of their team?