Re: Peer Review Process/Best Practices

Subject: Re: Peer Review Process/Best Practices
From: Ned Bedinger <doc -at- edwordsmith -dot- com>
To: Jill Mohan <jillemo -at- gmail -dot- com>
Date: Wed, 27 Feb 2008 15:35:48 -0800

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.

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.


Peer Review Process/Best Practices: From: Jill Mohan

Previous by Author: Re: Writers job description/definition
Next by Author: Word 2007 - where the 2003 functions are
Previous by Thread: Re: Peer Review Process/Best Practices
Next by Thread: [OT] Death of an outstanding wordsmith

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

Sponsored Ads