Re: The Problem With Keeping It Plain And Simple? (take II)

[eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com]

Geoff Hart wrote on 04/23/2006 09:49:26 AM:
> Some managers who don't know any better do use this kind of metric
> for semi-good reasons: for example, if you know that last years'
> documentation was 500 pages and took 250 hours to write, then as a
> crude guess, your writers need to hit at least 2 pages per hour to
> produce this year's version in the same length of time. Of course, that
> trivializes the work we do, but if you have no better way to estimate a
> project, I suppose it's better than nothing.

Actually, IMO, once you have a good work and production history to back
you up, then pages per hour is perfectly acceptable and in no way
trivialises how technical writers work.

You may spend more time on some topics than others, and some days produce
little or no "finished" pages. But at the end of the project, if the new
work is for a similar product, produced to the same degree of detail, and
the same level of quality. It should remain within the same pages per hour
envelope.

What's more important than the metrics is how they are interpreted and
used. So, if pages per hour (with suitable history to back up the numbers)
are used to generate deadlines and budget, no problem. If the same is used
on a weekly basis to evaluate productivity, then it's unacceptable.

Eric L. Dunn
Senior Technical Writer

_______________________________________________________________________________________________________________


This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is in
use and will browse through incoming emails.
Thank you.
_________________________________________________________________________________________________________________



Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l?usage exclusif du destinataire ci-dessus. Toute autre personne est par
les présentes avisée qu?il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance,
veuillez nous en aviser et détruire ce message. Veuillez prendre note
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la
sécurité de nos systems d'information et qu'elle furètera les courriels
entrant.
Merci.
_________________________________________________________________________________________________________________




(See attached file: C.htm)
<br><font size=2><tt>Geoff Hart wrote on 04/23/2006 09:49:26 AM:<br>
&gt; Some managers who don't know any better do use this kind of metric<br>
&gt; for semi-good reasons: for example, if you know that last years'<br>
&gt; documentation was 500 pages and took 250 hours to write, then as a<br>
&gt; crude guess, your writers need to hit at least 2 pages per hour to<br>
&gt; produce this year's version in the same length of time. Of course,
that<br>
&gt; trivializes the work we do, but if you have no better way to estimate
a<br>
&gt; project, I suppose it's better than nothing.<br>
</tt></font>
<br><font size=2><tt>Actually, IMO, once you have a good work and production
history to back you up, then pages per hour is perfectly acceptable and
in no way trivialises how technical writers work.</tt></font>
<br>
<br><font size=2><tt>You may spend more time on some topics than others,
and some days produce little or no &quot;finished&quot; pages. But at the
end of the project, if the new work is for a similar product, produced
to the same degree of detail, and the same level of quality. It should
remain within the same pages per hour envelope.</tt></font>
<br>
<br><font size=2><tt>What's more important than the metrics is how they
are interpreted and used. So, if pages per hour (with suitable history
to back up the numbers) are used to generate deadlines and budget, no problem.
If the same is used on a weekly basis to evaluate productivity, then it's
unacceptable.<br>
<br>
Eric L. Dunn<br>
Senior Technical Writer<br>
<br>
_______________________________________________________________________________________________________________
<br>
This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized
to receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is
in use and will browse through incoming emails. <br>
Thank you. <br>
_________________________________________________________________________________________________________________
<br>
<br>
Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir
des renseignements confidentiels ou protégés et est destiné à l&#8217;usage
exclusif du destinataire ci-dessus. Toute autre personne est par les présentes
avisée qu&#8217;il est strictement interdit de le diffuser, le distribuer ou
le reproduire. Si vous l&#8217;avez reçu par inadvertance, veuillez nous en
aviser et détruire ce message. Veuillez prendre note qu'une solution antipollupostage
(AntiSPAM) est utilisée afin d'assurer la sécurité de nos systems d'information
et qu'elle furètera les courriels entrant.<br>
Merci. <br>
_________________________________________________________________________________________________________________
<br>
<br>
</tt></font>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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 

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy.  Watch the demo at http://www.DocToHelp.com/TechwrlList

---
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 http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


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
http://www.techwr-l.com/techwhirl/ for more resources and info.