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.
This posting by Jane reveals all kinds of problems that have been discussed
here before. That part is OK; the problems should be solved.
re: The same developer has produced for a contractual document something
that he says is the final version. (The deadline is end-of-day tomorrow.)
Obviously Jane's company is not properly organized to take advantage of
in-house support by technical writers. There are exceptions of course and
cr*p happens, but most often it is a sign of poor organization that it ever
occurs that the tech writer is the last person in the chain of events and is
the one whose time is used up by others and who becomes the critical path in
project completion. Clearly projects should be organized with tech writer
involvement from the very beginning. It's quite easy to grasp concepts of
project management, and one useful concept is that an outline of the manual
or report can mirror very closely the project plan and the project goals ...
which obviously should exist at the beginning.
re: The problem is that the document is very technical. If I could get the
developer's time for an hour to go through it and check exactly what he
meant to write, then revise it, then have him review the changed sections,it
would be greatly improved.
The notion has been discussed many times on this list that the technical
writer is best off if he or she understands as much as possible the
technicalities of the product or service produced by his or her firm. Such
knowledge can be another benefit of the writer being involved with the
project from the beginning and constantly throughout, but it also should be
standard practice to "train" the writer in the company technicalities (I
don't mean the style guide) as part of new hire orientation.
These are classic mistakes made over and over, and good tech writers should
be aggressive and ensure their firms are best organized to utilize their
skills. There should be no assumption that management knows best as regards
how to use tech writers because there is too much evidence to the contrary.
There has to be an advantage to maintaining an in-house writing capability
(beyond just an editor service and as opposed to a secretary pool), and
frankly, I think even contract writers emphasize their past experience with
a particular technology when they can and would also most often recommend
their early involvement in any project.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17) http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads
---
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.
