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: Reviewers who don't review From:stevefjong -at- comcast -dot- net To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 01 Aug 2006 18:43:05 +0000
Reviewers who don't review boost my blood pressure, too.
I see two components to the problem, one generic to all jobs and one specific to
technical communication. My gut reaction is personal: *I* could never get away
with such a lame excuse for not doing my job, so how can they? I can't imagine
being able to get away with saying I didn't include information because I was
too busy to answer the phone, or listen to voicemail, or read e-mail, or attend
a meeting, or read a spec. Doesn't the negligent reviewer have a manager who
measures the reviewer?s job performance? I suppose the assertive thing to do is
to provide feedback to that manager. It's not something I'm comfortable doing,
but God knows it happens every day.
For technical communicators, review is often treated as a favor requested of
reviewers: would you review my document, pretty please? I'd be ever so
grateful... That leads to overuse of the carrot (chocolate et al) and reluctance
to use the stick (as evidenced by my discomfort 8^). As a coping strategy,
I have advocated getting doc milestones, especially review and signoff, onto the project manager's GANTT chart, at which point they become project milestones
and you gain an important ally in the struggle. (It's the project manager's job to wield the stick, after all.)
I also see an issue with the solution Gene offered (threaten to hold up the
release until the documentation is reviewed). This is a big stick, but is it a
real one? I've been in plenty of situations where the doc manager (sometimes
me) says, "We will never cause a schedule slip." That is in fact the
mantra of most tech doc group. I've been to plenty of status meetings
where--to mix my metaphor--every other group pulls that particular club out of
their bag, but never Documentation. Perhaps the writer who's too nice to rat out
his reviewer becomes the manager who's too accommodating to threaten to hold up
the release. But it's a big stick, isn't it? So, shouldn't we be using it?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
