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: Trouble working with a SME From:Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> Date:Thu, 31 Oct 1996 18:13:43 GMT
In article <3278E3F3 -dot- 50C2 -at- capsoft -dot- com>, "Melinda M. Carr"
<melindac -at- CAPSOFT -dot- COM> writes:
|> Okay, I need a reality check.
[...]
|> The crux of the matter is that he likes to review the documentation
[...]
|> and receive an explanation for each suggestion that we do not implement
|> (???).
[...]
Ooo. I am guessing that you provide a pretty clear set of instructions
to your reviewers regarding the scope of what you expect from them in
technical review. If not, start doing it. If the arguments you are
getting relate to changes your SME suggests, and those are outside of
the scope of what you asked him to provide, *your* argument is much
easier.
How easy it would be to impose this sort of restriction on the review
process *now*, when it is clearly aimed at your promblem reviewer, is
anyone's guess. Depends on how much crank your boss has, but it is sure
to escalate the tension in any event. However, it sounds like the
situation is pretty tense already, and getting worse. And you *do* need
to be in control of how you spend your resources on a project. Arguing
editing changes with SME's strikes *me* as inefficient.
It's never a bad idea to have clear reason for rejecting suggestions for
document revisions that reviewers constructivelyt offer. It sounds like
the reviewer is making suggestions outside of his area of expertise
(though he doesn't know that), and expects you to expend the resources
to justify your expertise to him. You might want to do that a time or
two, with your supervisor (and his) in attendance, if you can swing it.
Rely on firm tech writing principles, document design considerations,
readability, accessiblity, and other considerations he probably has no
idea about, and be prepared to back up your claims with formal
literature. And be fair; if he has a suggestion that makes sense, go
ahead and incorporate it.
You do that once, maybe twice, your problem may not recur.
If you do, and it does, I'm out of ideas beyond management intervention,
and that may not go in your favor. Then you need to decide whether the
aggravation is worth the money.
Hope this helps.
--
Len Olszewski My opinions; you go get your own.
saslpo -at- unx -dot- sas -dot- com
