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.
Jill Mohan wrote:
> This question may provoke only laughter - BUT, here goes...
>
> Is there anybody out there using a slightly formalized process for getting
> documents reviewed prior to delivery? If you are, can you share some best
> practices?
>
> Here is what we do currently - perhaps you could find remedies for glaring
> errors?
>
> Current state is -
>
> 1. I send out a doc to a mixed team of talent and suits.
> 2. Get silence for weeks.
> 3. I work the charm offensive going desk-to-desk asking for feedback
> on areas that match expertise of desk's occupant.
> 4. Trickle of feedback comes in from the charmed.
Reading advice on the web is one thing, but each tech writer
experiencing mushy review cycles needs to fire up the intuition, tune up
the empathy, focus on the problem reviewers, and find solutions for
their own organization.
That said, of course you can find plenty of advice by googling review
cycle; add techwr-l to the search to see what has been said here in past
discussions. It is a perennial topic that interests us a lot, and the
last word has yet to be written on the subject. But again, echoed advice
isn't your solution. Investigate why you encounter problems.
I think it is possible to make reviews happen the way I want, but I've
had to get inside the reviewer's head and see why they're not doing what
I want. One thing I've learned in this way is that I have to use
reviewers efficiently.
IOW, I would modify your step #1 so that I send *technical* reviewers
only the piece of the document that fits their area of expertise. I
would mention this to them when I send it.
Step #2 et seq have played out differently for my review cycle when
reviewers realize that I'm considering their qualifications as a
reviewer, and that I'm respecting their workload.
Perversely, some organizations require all reviewers to sit in meetings
where entire documents are reviewed, one line at a time. Expensive, yes.
But the time required to do it this way is built into the budget. I've
seen it happen, and the results are unparalleled for thoroughness. It
seems to awaken the sense of ownership, stirs awareness that the
documentation matters, and makes no bones about the fact that we're
childishly unlikely to do what we're told (because it's no fun) unless
we're made to. I prefer my way, but that's just me.
Hoping you discover something good and write about it here,
Ned Bedinger
doc -at- edwordsmith -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
