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: Metrics (oh no, not again) From:"Dick Margulis " <margulis -at- mail -dot- fiam -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 28 Apr 2003 14:57:26 -0400
Dan,
What are your goals?
If you write user doc, one metric has to do with number of Help Desk calls per sales unit. (That is, you don't care if the absolute number of calls decreases. You care if the number of calls per thousand new users decreases. So the actual measurement gets to be a little tricky, depending on how you "age" users, which will vary from product to product.)
What you are measuring here is the quality of the new doc relative to the old doc, as time goes on.
If you write development doc, then, sure, you want to measure how well you meet deadlines, because other people's work is dependent on the completion of your work. But you want to measure quality on these docs, too. So you might need to look at the statistics on whether the dependent steps get done on time.
For example, if you write a design spec for a new feature and the developer is able to knock out finished, working code in fewer days than was possible the last time you submitted a design spec for a similarly scaled feature, then that suggests a way to measure the improvement in your doc quality. Again, there are confounding factors, so you'll want to get a statistical guru involved in designing the actual metric.
What I'm getting at is that the metrics that are most useful are those that address the effectiveness of your documentation in terms of the overall project needs and company needs.
Obviously these quality metrics and schedule metrics have to be balanced against the costs involved. But that's the point of the exercise. ("With three people we were able to meet our target dates 75 percent of the time and maintain quality at a steady level. With four people we were able to meet our target dates 95 percent of the time and improve document quality so that dependent steps were completed on time 50 percent more often and Help Desk calls were reduced by 30 percent.")
HTH,
Dick
dan_roberts -at- adp -dot- com wrote:
>
>My company is having a big push for CMMI compliance, and as part of that,
>for business-related metrics (things like, "how long did it take an
>analyst to get a spec out" or "how many bugs were reported in development"
>or "how many bugs were reported by the client").
>
>As part of that effort, our doc group needs to determine our own
>business-related metrics.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Last chance to order RoboHelp X3 and receive a $100 mail-in rebate,
PLUS free RoboScreenCapture and WebHelp Merge Module. Offer expires
4/30/03! Order here: http://www.ehelp.com/techwr-l
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
