RE: Re; Validating documentation

Subject: RE: Re; Validating documentation
From: SIANNON -at- VISUS -dot- JNJ -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 25 Mar 2002 8:35:46


I think this thread is starting to get a bit sidetracked, as happens often
here on topics about which we have strong opinions. Due to the high count
of 'veteran' tech writers on this list, we are prone to disable discussion
of a problem by writing it off as the fault of "bad/immature business
practices". This is usually because the veterans have seen it all before,
and are familiar with the archetype, and both the issues and solutions that
come with it. Newbies, on the other hand, may not be as familiar, and may
not have the choice of avoiding the context of an employer's bad/immature
business practice.
We still need to address the question: how do we deal with the
validation of docs within our own context, and how would we deal with the
validation of docs in potentially less favorable contexts? The same
strategies may not work in different contexts.
Ignoring the question because the company hasn't reached a particular
maturity level, or because a few individuals contributing to the problem
haven't reached a particular maturity level, doesn't help those folks stuck
dealing with it right now. It is as much "blaming someone else" as blaming
reticent SMEs, and serves no constructive purpose besides possibly
identifying vectors for problems so that they may be included as factors in
evaluating possible solutions.

Now, sometimes, it *is* the business practice that may need to be
modified. Some companies still don't have SMEs _ever_ review their
documentation (no doc review process seems to be more common in situations
where the software is being developed for internal use, not for sale to a
third party). Some companies are still determining their documentation
needs (which offers a TW a chance to determine review practices, as I
believe was what prompted the original post). Some have had to deal with so
much change in a short period of time that the "standard" process gets lost
in the shuffle of reacting (e.g., with projects that change leadership
several times). Some have independent QA and testing teams, while some do
not (e.g., all testing is performed by the developers, or perhaps the tech
writer for the team). Some test from use cases, some test from the
requirements, some opt for another route entirely.

I, personally, have little to offer in the way of solutions right now
because I am still working on such context-originated issues myself. I
figured it wouldn't hurt, however, to try to bring us back to the question
since we seem to have strayed off in the direction of the "content
ownership" holy war again.

I look forward to hearing more preferred tactics,
Shauna

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at
http://www.ehelp.com/techwr

Check out the TECHWR-L Site redesign!
http://www.raycomm.com/techwhirl/

---
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.


Previous by Author: Re: Some more thoughts on knowledge management
Next by Author: RE: Occupational hazard - carpal tunnel
Previous by Thread: RE: Re; Validating documentation
Next by Thread: Data on who uses Help?


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads