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: measuring productivity From:"Zdunczyk, Ann Eleanor (Ann)" <zdunczyk -at- LUCENT -dot- COM> Date:Fri, 20 Feb 1998 15:59:56 -0500
We're a translation group and our management wants to measure our
productivity on the different Software Packages that we use. They tend
to forget that no matter how good we are with a package, what is
dictating the speed in which we do our jobs depends greatly on how well
the customer new the package in which they did their documentation. In
PageMaker we have had a 200 page document where there was no flow
between pages but the translation grew 30%, we had to reconstruct the
document. :-(
========================
Ann Zdunczyk
Technical Support Specialist - JOAT
Lucent Technologies
ILT Solutions
zdunczyk -at- lucent -dot- com
Voice: (336)727-3782 (Area code changed from 910)
FAX: (336)727-3078
========================
>----------
>From: Miki Magyar[SMTP:MDM0857 -at- MCDATA -dot- COM]
>Reply To: Miki Magyar
>Sent: Friday, February 20, 1998 3:04 PM
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>Subject: measuring productivity
>
>Kathy Borgtodd asked " how do you measure productivity in your department? "
>
>Good question! Usually the answer is, we don't - we get evaluated on whether
>or not we got the manual/help/etc. out on time, on budget, and with approval
>from the client reviewers. Since we work on any given project as a team, and
>are subject to any number of external constraints beyond our control, this is
>about the only thing that makes sense.
>
>'Productivity' on an assembly line makes sense. 'Productivity' in Tech Pubs
>needs to be clearly defined. Or better yet, ignored. What is the purpose of
>the measurement? Who is going to use the information, in what way? The answer
>is in the question - if you are looking for process improvement,
>'productivity' is not necessarily what you want to ask about.
>
>That said, yeah but, and on the other hand -
>Each case is different. If you're churning out updates of a catalog,
>'productivity' may be a valid measure.
>You can't make improvements until you know where you are. Just make sure your
>baseline and metrics make sense for your purpose.
>If you're trying to evaluate tools, 'productivity' may be a key factor.
>Again, be sure you know what you're measuring.
>
>I'm looking forward to the discussion on this one!
>
>Regards,
>Miki
>mikim -at- mcdata -dot- com
>
>
>
>
>
>
>
>
>
>
>
>
> !
>
>
>
>
>
