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.
Peggy Lucero wondered: <<I have 10 technical documents, varying in
length from 60 to 600 pages. They need to be reviewed, starting 2/1/06
and ending in mid April.>>
No miracles required. Worst-case scenario (6000 pages in total, 20 days
per month), that's less than 100 pages per day, and if most of the
books are smaller than 600 pages, the task becomes feasible. Provided
the material was carefully prepared and is well edited before it goes
for review, this is an achievable target.
<<They need to go to: 1. Peer review 2. Client review>>
The first question to ask is how many reviewers there will be; more
means less chance of reviewer burnout than if each reviewer must review
each document. Consider giving your reviewers a break by assigning
reviews to the person most qualified to do them instead of forcing one
person to review everything. The second question is about whether the
peer and client review can be conducted in parallel. If they can, the
problem becomes easier. If not (often the case), you cut your time for
each phase to only about 1.5 months, and that makes the pages per day
climb into the potentially unachievable range if each reviewer must
review each document.
<It seems a consensus that 5 days are ok to allow as the time period
for each document to be reviewed in, though for the one really long one
(almost 600 pages), I've recommended a group review meeting, that I'm
suggesting will take 4-5 hrs, but, I actually have no idea how long it
is likely to take.>>
Setting a single review period for documents of different lengths is at
best unkind to reviewers who get shackled with the longer documents,
and at worst, a lousy way to estimate review times and schedule the
reviews. All else being equal, review time is directly proportional to
the length of the document--that is, longer documents require more
time. So always set review durations based on days per page.
Here's one data point. I edit very quickly compared to most--ca. 1100
words per hour for two passes with heavy substantive editing. Double
that because your reviewers will typically make only one pass (2200
words per hour) and because they won't be doing heavy editing. This
means (conservatively) about 4 single-spaced pages and 9 double-spaced
pages per hour. Call it 5 and 10, respectively, to make the calculation
easy. Now let's assume 5 hours per day of review time (probably a bit
high if reviewers actually have their own work to do, but the
calculations remain easy). That means 25 and 50 pages per day,
respectively. Now you can estimate a "fair" review time for each
document based on these rates. Real reviews should go faster.
Second, time requirements depend heavily on reviewer availability. Find
out when each of the reviewers is most likely to have time available
for the review, get their commitment (ideally "in person" or over the
phone) to do the review at that time, and send them the review at that
time--not earlier, unless they're willing to renegotiate the deadline,
and definitely not later. Find out their preferred review format (Word
file, PDF, printout) and send them that. Confirm their availability a
week or so in advance of the scheduled review, and have a contingency
plan in case they have to bail at the last minute because of some life
crisis.
Third, review meetings are generally the least effective way to review
a whole document. If you must use a meeting, make it efficient: review
all the edits and comments before the meeting, and at the meeting,
discuss ***only*** the areas where reviewers disagree. Send everyone a
copy of the disagreements several days before the meeting so they can
think them over, discuss them with the other reviewers, and come to
some consensus (so you can record their agreement and remove it from
the agenda) or agree to disagree (so you need an in-person meeting with
you arbitrating to broker a compromise).
<<... no two documents overlap. In other words, I'm only to give
documents one at a time to a reviewer because if they get more than one
at a time it is believed they'll get 'overloaded' and never get
anything reviewed and returned to me.>>
This is a real risk. Plus, large documents can create a massive
psychological impediment to getting started, plus a desperate need to
burn through the review rather than taking the necessary time. Consider
sending reviewers small chunks (e.g., chapters or sections) rather than
the whole manuscript. This makes it easier to fit the reviews into a
busy day (you can edit a chapter over lunch, but knowing that you can't
do that with 600 pages may lead you to spend lunch playing Tetris
instead) and gets the job done sooner. Of course, ask their preference:
some people (editors like me, for instance) really do prefer to get the
whole manuscript at once and slog through it.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
