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.
Thanks to everyone who responded. You all gave me a
lot to think about.
I realized as I got the comments that I left out a
crucial piece of information...the manual went out to
our managers and maintenance specialists in the field
(we have offices all over the United States). Thus, we
can't hold traditional meetings.
Anyway, on with the summary.
Several people thought that the spreadsheet idea was a
good idea and had some improvements/refinements of the
process.
Lee Tesdell suggested:
"Try categorizing the comments first. I would suggest
that you come up with say four categories of comments
first: content, organization, clarity, and grammar,
for example. Then sit down with several colleagues and
categorize all of the feedback that you have received
under those four headings. You'll probably benefit in
two ways: (1) you'll find that there is duplication
and therefore you can eliminate some of the comments,
and (2) you'll have a better organized set of
comments to track."
Lynda Straus reviewed how she got and consolidated
comments:
"I took each policy, one at a time, and spoke with all
affected parties, sometimes in meetings, but often
individually. They also got together in small groups
on their own when they realized that the tech writer
was getting conflicting info (as they could see from
all the reviewer's comments on all the copies I
carried around) and came to a consensus and then
notified me."
<A poor pitiful me moment>
I wish that would work here! Everyone gets excited
about the manual, but no one really wants to commit
their knowledge to writing. I get conflicting
information all the time - often while meeting with
the group. I usually end up summarizing it all and
forcing them into a decision. Outside of the meetings,
I have to drag information out of the SME's.
</A poor pitiful me moment>
Geoff Lane took the spreadsheet idea a step further
and suggested that it might be more practical to
design a database in Access. Doing so offers the
ability to
sort data and a flexibility of presentation. Further
discussions with him ruled this out, since I don't
have any experience with databases or Access and this
situation should be a one-time only thing. Here's the
heart of his post:
"I spent about a day and a half writing a custom
Access database. That way, I could filter the comments
by subject, SME etc. to get exactly the views needed
when discussing a particular topic or preparing
discussion notes for a particular SME. This is much
more flexible than a spreadsheet. Even if it takes
longer to set up, it pays dividends when you need to
quickly get to the nub of a topic.
And, as Guru Kamath pointed out, this idea was covered
at the STC Conference in
Cincinnati last May:
"...Janice Gelb's talk at Cincinnati (STC Conference)
on Making Technical Reviews More Efficient...covered
how to use a database to track review comments.
(Janice was the Project Lead for Read Me First -- the
Sun Style
Guide.)
If you have access to the STC Conference Proceedings
of May 1999 in hard copy you will find it on page 342.
If on CD, you can search it by author. I am sure it is
available on the STC site at http://www.stc.org too.
I also feel that you need some kind of automation
(mainly macros I suppose)to pick all the review
comments and consolidate them. Tracking corrections
may not be necessary as these are straight-forward --
it is comments which usually need resolution."
James O'Brien's suggested that I take the process
online:
"[The] comments would have the reviewers initials
attached, they're matched to the text, and it's all
on-line. Also, making reviewers type in their notes
in a copy of the doc is a step towards legibility and
makes people more concise (in my experience)."
I'm not sure exactly how this would work. My view on
it would be to have everyone type up their suggestions
in an email or in Word and forward it to me.
This won't work in my situation because:
1. This suggestion requires advanced planning, and I
didn't know that 60-odd people would review it until
the morning the manuals were to be sent out. There
were originally only 8 to 10 reviewers, and all of
them are in this building with me. However, at the
last minute, the director decided that all of his
people
needed to review it. I spent the day making 60 copies
and stuffing envelops, and wasn't able to doing any
planning.
The result is that I'll probably get comments in all
shapes and forms, from emails to returned manuals to
letters. I have a feeling this will turn into a
organizational nightmare, since people would forget to
include simple things like the page numbers and/or
line numbers (no matter how many times they're
reminded).
2. I don't have a company email, so I'd have to use a
web-based email account. Neither I nor the company
would be comfortable with this. There may also be
difficulty getting to the site, limits on size, et
cetera.
One way this might work is to build a place on the
intranet where everyone could deposit the suggestions.
This would allow some form of cooperation since one
reviewer could read another's comments and draft a
reply, thus facilitating discussion. I would have to
explore this idea more.
Lyn Worthen pointed out one disadvantage of using a
spreadsheet. I think it could be applied to all the
methods I just discussed. You can't see the original
document, and therefore cannot compare the two.
And then Paul Hanson made a brilliant observation: "I
wouldn't bother with a spreadsheet. Why waste time
re-typing suggestions/corrections?"
So simple; so profound.
Based on this idea, a couple of people suggested the
use of a three-ring binder. The first step is to make
a single-sided copy of the manual and put it in a
binder that is much thicker than the manual (put a
2-inch-thick manual in a 3-inch binder).
There were two takes on this idea:
1. (Suggested by Paul Hanson) "I would request that
when someone finds something that needs to be changed,
they photocopy the page and mark what they think needs
to be changed. Also have them initial their
suggestion. Then insert it into your binder, but put
the bottom hole in the middle ring and the middle hole
in the top
ring. Your page will stick out.
Collect all the suggestions. Make the straightforward
ones right away and mark the page that sticks out as
"DONE" in one color (like black ink). TIP: WRITE BIG
so you can see the status of the page right away. For
the ones that have content changes, mark those as TBD
(To Be Discussed) and use red.
When you collect a bunch of suggestions for a certain
section, photocopy the marked up suggestion pages,
staple them and use this as a packet to go through.
That way the SMEs see what each SME has marked. This
gets you out of the loop: you just have to facilitate
the discussion with something like: "Bob marked item
1 as needing to refer to ABC, but Jim marked item 1 as
needing to refer to CDE. Should it be both or which
one?" and let them debate. Keep chiming in with "So
what you're saying is ABC AND CDE should be put in?"
Ask for a consensus.
The pages sticking up are how I used to keep track of
changes that had to be made to the 3 manuals I
maintained. I could look at a particular manual and
see what changes I had made and what I needed to do
yet. I then kept that version of the manual for a
whole release process."
2. (Suggested by Lyn Worthen) "When I have a number of
feedbacks, I've printed a single-sided copy of the
document, put it into a looseleaf binder, and used the
blank page on the left to compile the notes specific
to the facing page. That way I end up with all the
reviewer's comments (referenced by source) and the
original document in one location, which is very
helpful for comparing the original document and any
conflicting reviewer's comments."
I like this idea: it's simple and elegant - and saves
a lot of typing time. In fact, when I was an
undergraduate, I used Lyn Worthen's method for taking
notes in class (I'd leave the left pages blank so that
I could add my own summaries, connections, et cetera.
It is especially useful when a teacher starts of
saying "there are four way that this is important."
S/he the elaborates on each point in turn. I could go
through and write in "the four points" in one
easy-to-handle list.)
So here's what I'll probably use (refining it as I
go):
I'll place the manual in a 3-ring binder. As the
manuals are returned, I'll find the pages with
comments and take them out of the manual. After coding
them for
the reviewer, I'll punch holes in them and place them
in the binder so they face the original page. To make
them stand out, rather than using Paul's offset method
(which seems a bit messy to me - no offense intended
to Paul), I'll use post-it notes to mark what I will
need to discuss with the SME's and a paper clip to
hold together all comments for a specific page. To
help the discussion, I *might* attach a brief summary
of the
reviewers' comments.
Since I like the idea of color coding, too, I'll use a
highlighter to mark the categories: grammatical,
clarification, et cetera.
Thanks again for the comments, folks! This list is great!
=====
Jeff Hanvey
Memphis, TN
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/