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:Re: ANON: Feature Incomplete Training Issues From:Ed Gregory <edgregory -at- HOME -dot- NET> Date:Wed, 20 Jan 1999 08:30:26 -0600
At 04:30 AM 1/20/99 -0700, Anonymous wrote:
(SNIP AND SUMMARIZED: about having to do training on an imcomplete, untestable
product.)
1. This shows again the value of documenting your documentation process. If
you have source material -- activity scripts, flow charts, etc. -- from the
SME
and it is archived as reference material for your work, you have proof in hand
that the problem is in failed functions, not dowdy documentation.
2. If you have created a training outline based on what the SME says the
product should or will do, get the SME to review your outline and
approve/disapprove/amend it.
3. Keep key people in the loop on the status of this review.
When I send something to an SME for review, I use email to formally
announce its availability. I ask for a time frame on the review. I mention how
vital the review is to ensuring that we have accurate and effective
documentation. I mention any deadlines of which I am aware. I mention the
users. I speak in terms of team work.
I also mention the functions that I was unable to test successfully. I
mention that these unexpected results are noted in the document the SME has
in
hand for review.
I carbon copy my team leader and the SME's team leader. The team
leaders
know better than I how thin this SME is spread and whether the SME is
adequately addressing issues crucial to the completion of my/our work. Also,
the team leader - and others that I've kept in the loop - know the whys and
whens of any delays or gaps in my deliverables.
If you are a competent writer, you can craft a communication that is
gracious and, with a little luck, effective.
I also attend status meetings, and, if invited, report that the
documentation is in the hands of the SME for review. I don't bring up
individual detailed problems. No need to publicly embarrass either me or the
SME.
