Re: text production process

["CB Casper" <knowone -at- surfy -dot- net>]

CB> Sitting down and talking to the ones involved in 
CB> preparing the materials and determining what they 
CB> need, when they need it, etc. can make a big
CB> difference.

AP thought something was added with:
AP> ...and eat up all sorts of time. Why work 
AP> when there are MEETINGS to be had! 
AP> 
AP> A doc department should take information from any 
AP> source it can get it. If you put a sphincter in 
AP> front of your work, you get shit. 

Taking in anything provided may work for simple 
linear work flows, such as 
Engineer/Info -> Writer/Documentation.

It's not as simple with more complicated arrangements 
typically found in large companies. Aerospace 
systems may have many groups involved and the 
information flow gets complicated very quickly.

A simple example. The design engineers saved their
drawings in a proprietary format. When we needed
a drawing, we had to ask them individually to save
a CGM file for us. This always got them upset, as
they were working on another drawing. Another
option was to have TW's to gain access to their 
system. That would have taken a $25000 investment 
in training, hardware, and licensing, for each TW.

Once I explained this to the designers, they 
understood the consequences, costs, and how easy 
it was for them, they agreed to always save the
finished drawing as a CGM to a location we could
access without compromising their systems.

If 'Yeah right. Put 10 people in a room and try 
to get them to agree on anything' is the
experience when working in a group, then I
suggest that someone skilled in leading 
cantankerous groups be called in.

With a softer approach to problem solving and
cooperation, disparate groups can agree on a 
process, I know, I've done it. When it is in 
their own best interests, it's even easier. 

Is this activity typical of a Tech Writer, no,
but it should be. Why? Because the TW knows what 
content is needed when and where. If we apply
our knowledge of content to a broader view,
we can increase our value to the company.

In the example in my earlier post, I took a
2 week documentation cycle and reduced it to
2 days. Evaluating a process and making good
changes saves the company money, and lets the
TW's focus on creating content, not spending
time and money chasing down bogus and duplicate
information.

Just as a responsible TW would get the product
fixed if flaws were found, frequently the TW
is in a position to see flaws in the information
flow process, and should take steps to correct
them in the interest of the company.

CB - have process? will fix
-- 
Surfy! http://www.surfy.net  Great web search, free web email, and $9.95 unlimited Internet access

Powered by Outblaze


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.

A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.