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.
Subject:RE: Tim - Levels of Edit From:"Blount, Patricia A" <Patricia -dot- Blount -at- ca -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 10 Apr 2008 09:57:04 -0400
Hi, Tim,
Glad you liked The Levels of Edit doc from Bonnie.
My two cents? I've used that document in a former management role where
no formal QA or editorial process existed.
You've heard that old saying, "Fast, cheap or good, pick any two?" That
was how I applied the levels of editing concept here. In our
environment, development was a team process so my "edit levels" had to
align to each team member's responsibility, i.e., instructional
designers, trainers, writers, artists, and computer programmers. I
wanted to make sure I wasn't wasting the time of six people by having
everyone checking for typos. We followed the JPL principles and began
classifying who should be responsible for what. IDs were responsible for
ensuring the instruction could be measured in terms of performance.
Programmers were responsible for the accuracy and completeness of
procedures. And writers were responsible for typos, grammar, brand
identity and so on. (There was more, but this gives you an idea...)
Next, we tried to classify our deliverables according to some sort of
importance rating. Which ones truly needed to be reviewed by every team
member? For example, a course description did not require a computer
programmer's review, but did require an instructional designer's and
writer's, while an instructor guide required everyone's review - which
I'd consider to be equivalent to JPL's 'substantive' edit.
We then built the reviews deemed required into the process.
Now, you know what happens in the real world... inevitably, someone
directs you to produce a full deliverable in a fraction of the time.
Effort is effort - it cannot be squeezed to fit a schedule without
sacrificing something else, i.e., budget or quality. With our levels of
edit process, it was easy to push back and say "X is what we can give
you...if you want Y, we need Z."
Feel free to contact me off list if you want more details.
Patty B.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-