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.
> ...Writers should be working to complete deliverables
> that are accounted for in a project plan. Each deliverable should be
> associated with the anticipated amount of effort needed to complete
> it (person-days, basically). ...
>
> Then the question is how well did the writer do in terms of producing
> the deliverable in the expected time, and the metric at the
> end of the year is the ratio between estimated effort and actual effort.
...
This is neat, but I suspect deceptive. In my environment it would be anyway.
When we don't hit a deliverable, 99.999% of the time it is because we didn't
get source from the SMEs, or a dev deliverable slipped, or a customer
requirement changed midstream, or some sexier project swiped the writer(s)
or SME(s) in the middle of the project.
It's also NOT all equal. Producing a new set of docs is not at all the same
task as updating an existing set. Producing an updated set of docs that
includes reorganizing the standard content into more useful deliverables is
not the same task as producing an updated set of docs that uses the same
organization we've used for the past three years.
We are trying to come up with meaningful metrics now too. My part of this
effort is to break down tasks and timelines in ways that are meaningful
given the particular project. Sometimes I can tie doc milestones to dev or
deployment milestones. What I am finding more and more often, though, is
that each project requires sensitivity to its own particular milestones.
This takes real-world experience and analysis of what to expect from each
team and each product/project. Some are cowboy, some are high-risk. Others
are predictable and managed strictly by the book.
At some point, it's probably possible to come up with a formula that uses a
standard formula AND multipliers for factors that complicate the
documentation task, such as the SME availability or need to reorganize that
I mentioned above. (The "weenie surcharge" -- which is a pure percentage I
apply to both time and cost estimates -- that I developed to deal with drama
addict clients decades ago is still useful and necessary, but needs to be
hidden more carefully in the corporate world.)
Ultimately, the usefulness of numbers is based on the degree of trust the
manager(s) who implement(s) them inspire. Writers who trust their manager
will work to and be inspired by her ratings. Upper management that trusts a
doc manager will reward and respect the documentation team's effort.
Is that terribly different from any other job function?
Kate Robinson
TechComm Editor
Alaska Building / 206-792-2146
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
They have been at a great feast of languages,
and stolen the scraps.
-- William Shakespeare
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
