Re: Peer Review Process/Best Practices

Subject: Re: Peer Review Process/Best Practices
From: "Wanda Phillips" <wanda -dot- jane -at- gmail -dot- com>
To: "Jill Mohan" <jillemo -at- gmail -dot- com>
Date: Tue, 26 Feb 2008 15:12:36 -0800

This place that I'm at right now is, by far, the most amazing place in
the world right now. The only thing missing is the Margharetta
delivered to your desk at the end of the day....
Seriously though.
Reviews! Even with our rigid and rigorously enforce process there are
loose flaps, gaps where the feral reviewer can escape.

1) We are bicoastal.
2) Our product teams are run by a small group of representatives.
3) We base our review list on the requirements specified in an
auditable process.
4) About a week before the review is to start, we send all mandatory
and optional reviewers a message telling them that this responsibility
is theirs for this release. We point them to the process documents
(and then they use our training system to tag the document as read).
Theoretically, all reviewers MUST read the rules of engagement before
engaging. They should, at least, sign off, pretending to have.
5) We create a PDF with comments enabled and distribute it, via email,
to the reviewers (mandatory in the To list, optional in the CC list).
We give them 1 day to 2 weeks (depending on the manual) for review. We
tell them that they can pass it along to others, but that they, then,
are responsible for ensuring those others get their comments in on
time.
- The email we send out is a standard structure that has standard
text and then places to put notes and information about the manual to
be reviewed. The email includes a list of things we DON'T expect the
reviewers to handle, grammar, page layout, image quality... we assure
them that they are looking at a DRAFT of the document and that our
processes hand any typos, layout, or grammar problems, that our
reviewers are working along side all others, looking for the problems
in the domains in which are the SMEs.

5) A day or two before the end of the review period, we send out a reminder.
6) A day after the end of the review period, we consolodate the
comments into a single PDF.

For late reviewers, we send them a reminder and we cc our manager and
their manager, and, better yet, the project manager. The functional
manager may not have any real investment in the review but the project
manager is judged by the lockstep march of their project team and
project through the streets of conformation and reliability.

Generally, this is sufficient. On one product, I have a reviewer (the
product manager), who is juggling the load of maybe three people. He's
ALWAYS late. I have learnt a number of badger techniques for wearing
him down; I'm always polite, even jocular, but persistent.

Finally, it's my job. The world isn't going to end if I'm not treated
with deference and respect by coworkers, most of whom don't experience
deference or respect in their jobs. This past year, while I went
through a whole drama about my job (the Damacles sword of visa
qualification hanging over my sweating brow) I realized I invested way
too much of myself in this. I can do my job without taking it
personally that someone is too busy to do their job the way I think
they should.

In the end, I always get good feedback from the tardy reviewer and I
get excellent help in understanding the product, it's positioning, and
the implications our products and their features have in our users'
workflows.

I no longer bribe. I no longer whine. I ping the reviewer several
times a day (we use Sametime in-house, so whenever I see his name pop
up, I send him a note). But, I carry on with my job.

Wanda
--
Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people
are even incapable of forming such opinions.
Albert Einstein
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


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
http://www.techwr-l.com/ for more resources and info.


References:
Peer Review Process/Best Practices: From: Jill Mohan

Previous by Author: Re: Testing an index
Next by Author: Re: Peer Review Process/Best Practices
Previous by Thread: Re: Peer Review Process/Best Practices?
Next by Thread: Re: Peer Review Process/Best Practices


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


Sponsored Ads