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.
I'll reply wearing my project manager hat today. From this perspective,
time sheets are of vital importance. If you are working on one project
for the next six months, then no, a daily time sheet isn't really that
useful. However, if you are working on integrated projects with
different deliverables, then you definitely need to account for your
time. There also needs to be a history. I go to my timesheet database
several times a day. I need to make sure that the jobs have been costed
properly, I need to dig up historical info to support a proposal (well,
it took us 10 days hardware engineering time to make that change, we'd
better bid the same this time). I need to compare time sheets to work
packages. And not because I want to come down hard on someone, but just
to make sure we know what happened. "Well, we gave you five days, but it
took 12. What went wrong here? Did we estimate badly or were there other
factors?"
Bob Morrisette wrote:
>
> Starting today the writers in my group are required to
> fill out a web-based form showing how much time they spend
> on each document during the day.
>
> The form lists all documents assigned to you and time for
> meetings, reading, etc. They don't list time in the bathroom.
In most situations, it's easier to start with more detail, and then
relax, than it is to go really broad and try to fill in the details. I
suspect this is what your "metrics queen" is trying to do. After six
months or so, there will be an analysis, and then a new revision of time
codes.
The truth is that an accurate picture of time spent doing various tasks
is vital for all kinds of reasons: job costing, proposals, R&D tax
credits, project planning etc. Time metrics are a requirement of various
process models, and CMM if I'm not mistaken.
"Higgins, Lisa" wrote:
> I've had to do this in the past, and it can be very difficult. When you're
> working on several projects, it can take a lot of time to keep track of when
> you're doing what, and it's a judgement call what you document for this.
> What if you're working on one thing, and someone calls or stops by with
> information about a different project? Do you note that? Is there some time
> limit?
Well no, the point isn't to make it your primary task, but if (for
example) you spent 20 hours supporting marketing and not working on your
other projects, the company needs to know that not only are your other
tasks not the time drag you'd assumed, but that marketing requires a lot
of support. 15 minute intervals is good to aim for, but there will
always be flexibility. There's no reason not to jot down start and
finish times in your daytimer. If you spend more than say 20 minutes
doing something else, take 15 seconds to jot that down too.
> (And no, I really don't think it's appropriate for anyone but MAYBE the most
> junior level writer. Anyone with any experience has probably figured out the
> most effective way to work, and I can't imagine what they'd want to do with
> this information except dictate some oppressive, inefficient, soul-sucking
> working model. Or maybe it's a contest to see who goes to the most
> meetings.)
It isn't meant to be "soul-sucking", but project managers and planners
definitely need to know what work *acutally costs*. It probably has
NOTHING to do with making sure you're really working, or being big
brotherish or whatever. I've never had a job where we didn't fill out
time sheets, and I never expect to have a job where I don't insist that
they be done.
--
Ginna Dowler
Project Manager and Documentation Supervisor
Quester Tangent Corporation
Sidney, BC
gdowler -at- questertangent -dot- com