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.
> However, when doing TW contracting, I have often found that the client does
> not have an adequate set of rules; he most often solicits me for a
> significant number of rules (methods, procedures, etc.). I don't have any
> firm rules, just suggested guidelines. So, I - per the customer - go that
> route. Problem: My suggested guideline, at some point, violates some
> UNSTATED client rule.
I'm surprised that so many engineering companies here in Silicon Valley don't
understand the basic seven-step approach to documentation. (Outline/schedule,
first draft, first review, second draft, second review, final copy, production.
Granted that there are LOTS of variations on this, but that's the gist.) Nor do
they understand the ramifications of adding or deleting steps. Nor do some
understand that you can't keep changing a product right up to production time
and expect the docs to be accurate or on time. So when we take on a new
contract, we make sure that the responsible parties understand the rules and
the probable effects of breaking the rules.
That doesn't stop some of 'em, of course - and we've seen rule-breaking by some
large organizations who've been around forever, with the predictable results.
But it does help, when the finger-pointing starts, to remind people of the
earlier process explanation, if you can do so tactfully.
I can count on the fingers of one hand the number of engineering projects that
have gone according to plan, however. There are always things that people
forgot, or features demanded by important customers, or some situation that
couldn't have been foreseen. And a good technical writer will do what it takes
to deliver quality anyway, and as nearly on schedule as possible. AND keep
good notes on what happened.
Elna Tymes
Los Trancos Systems
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sponsored by Weisner Associates Inc., Online Information Services
Training & consulting for RoboHELP, Dreamweaver, HTML, and HTML-Based Help.
More info at http://www.weisner.com/train/ or mailto:training -at- weisner -dot- com -dot-
Sponsored by Rose Hill, Your Business and Career Coach.
"Assume Success! Live Your Passion!" Get the gist at
www.coachrose.com then call 503.629.4804 for details!
---
You are currently subscribed to techwr-l as: meldard -at- ZZSOFT -dot- COM
To unsubscribe send a blank email to leave-techwr-l-10115D -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.
