RE: Metrics for Technical Writing.

Subject: RE: Metrics for Technical Writing.
From: mlist -at- safenet-inc -dot- com
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Tue, 25 Apr 2006 12:11:46 -0400

> -----Original Message-----
> From: Giordano, Connie [mailto:CGiordano -at- tiaa-cref -dot- org]

> Big topic on the list right now. I started working on some
> metrics development when I was over at Time Warner Cable. We
> had to collect some baseline statistics first, and ended up
> using Remedy, the trouble ticket/work request solution that
> all developers, deployment teams, and support personnel used
> (and one more way to shift to a culture of inclusion for
> technical communicators)

> So we determined some likely categories, types and items to
> group together similar kinds of requests. For example:
> Project Communications Plan, Application Administrator Guide,
> IT Mass Communications, Security Policy, and so on. The
> system allowed us to track actual time spent, reassign
> tickets when it was time for review/approval, and close them
> out upon publication or distribution. At the end of the year
> I was able to develop metrics based on the number of tickets
> by operational group. Rather than doing page counts, we
> started being able to estimate turnaround time by type of
> request, etc.

I'm not quite clear on how the time-tracking aspect is
achieved. When the employees are filling out the timesheet
form, do they record a block of time against a trouble-ticket

A couple of things mitigate against accuracy in that
situation, at least for the kind of documents that I

One is that several trouble-tickets might be resolved
by a single (or cluster of) modification or addition
to the documents. Conversely, several documentation
or code changes might resolve just one problem.
My experience of time-reporting systems is that you
could spend as much time trying to make your
hours fit the work as doing the work. It gets complicated
if you also have to choose/apply charge-codes that are
later used to justify contract billing or government-
program grant money. The people entrusted with tracking
that stuff and justifying the claims usually have nice,
concise (and generously inclusive) sets of rules for
deciding whether a given activity should be charged
to a given project, but you can tie yourself in knots
if you try to conscientiously apply them.

The other is the way that many (most?) employees fill
out timesheets. They wait until the end of the day,
or the end of the week, then go back and juggle the
charged hours until they add up to a workday or workweek.

Say I've spent a couple of hours in meetings today, and
we happened to discuss items that might apply to several
open trouble tickets. Do I go for the smallest increment
of time that the system allows, and charge (say) 15 minutes
to each vaguely-related trouble ticket? Or, since the
meeting at least brushed some subjects that apply to
that research grant, do I "bill" the meeting against
that charge-code... and the company claims some money
from a government program? Other?

Bottom line is that my personal timesheet must reflect
(at least) the number of hours that makes a standard
workday, and only a certain small percentage is allowed
to be charged to "Admin-general". So that is made to
happen. Same applies to any developer or other employee
(at any company where I've had to use timesheets) -
the fudge factor is high. Nobody goes home without
having worked a full day, on "paper". Some people
agonize over getting both the numbers and the "correct"
charge-code just right. Others just toss in numbers and
notes that keep management off their backs. Personally,
I go through phases of both, depending upon how pressed
or frazzled I happen to be.

I don't think a manager would be encouraged by that
sort of admission. Perhaps in large-enough companies,
it all just averages out to some sort of "truth" about
how much time and effort gets expended on this or that.
We know people who just put their heads down all day
and work steadily, and others who goof off (or allow
ideas to percolate in their subconscious) between bouts
of intense activity. Both produce good work.
Should the second bunch charge only half their days
to work codes and the rest to "nothing that we should
be paying you for"? The very fact that somebody
turns in a full timesheet when they actually spent
significant time socializing or staring out the window,
or talking to the babysitter, or arranging doctor
appointments, is a lie, isn't it? That undermines the
integrity of the system, and possibly of the employee
who has to fib every day, as a condition of continued

I'm not sure that the averaging magic can work all that
well in smaller companies or divisions.

Or it might be that I just hate filling out timesheets.

Kevin (no, the other Kevin)

The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!.

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

Previous by Author: RE: The Problem With Keeping It Plain And Simple? (take II)
Next by Author: RE: Metrics for Technical Writing.
Previous by Thread: RE: Metrics for Technical Writing.
Next by Thread: RE: Metrics for Technical Writing.

What this post helpful? Share it with friends and colleagues:

Sponsored Ads