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.
If I were you, Hope, I'd be very concerned about management's using the
number of pages written to determine if staff members are improving.
It's much easier to throw words on the page (and move the page count and
productivity stats up) than to write crisp, clear documents that meet
the reader's needs. In other words, by rewarding writers for page
count, that's what they'll get - lots of pages. This could artificially
increase book size (and resulting printing costs) just so writers "look
good" in their stats. IMHO, bigger books don't necessarily contain
better or more information, and they can be harder for the customer to
use (more words to scan through to find the info you really need). Bad
idea (same problems as tracking lines of code for programmers - sloppy
coding just to get the stats up)!
This is how it works here:
1. We estimate time to completion for each book for each release, then
we track actual time. We're expected to estimate within +/- 10% of
actual. This comparison helps us become better at estimating for future
projects so they are more likely to stay on track for the estimated
release date.
2. We judge our performance by whether we meet our deadlines. We're
all on salary here and are expected to work the hours necessary to get
the work out the door on time. The better you estimate your time up
front, the lower the chance that you will work significant overtime. Of
course, if the programmers add one more "little" feature right at the
end... it always happens, so we all pad our estimates to cover this
certainty.
3. We monitor Support calls to ensure that FAQs are adequately covered
in the books and online help. If we can answer the user's questions
with the docs, we reduce the calls to the Support line. This is an area
where we can make a big difference to both our clients (saving time and
aggravation) and our company (saving money). By restructuring a
Training Guide and linking it to the online Help for aone of our
products, we were able to convince users that the online Help actually
contained what they needed to know, and teach them to use it first
rather than just calling Support. This reduced our Support calls by
_33%_ - now, that's a benchmark that means something!
4. We are active members of the development team and represent the user
in the area of interface design. This gives us the chance to modify
programmer wording in dialog boxes, menus, and messages to improve user
understanding (and reduce Support calls). It also gives us a heads-up
on new or modified product features.
5. Even though Pubs department members work on different product lines,
we meet regularly to discuss ways to improve general content and
processes. If we can find a faster way to produce a quality product, we
all win.
Good luck on convincing them to ditch the page count stats idea, and
find something to measure that really means something to the user or
company.
*************
Kim Cramer
kcramer -at- ncslink -dot- com
Sr. Information Developer
NCS Education, Mesa AZ
*************
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
