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.
> 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
number?
A couple of things mitigate against accuracy in that
situation, at least for the kind of documents that I
do.
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
employment.
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!. http://www.webworks.com/techwr-l
