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.
Some great comments below! Especially about the need
to base estimating upon first properly "chunking"
tasks into right-size [and approx equal-size]
pieces!!! Of course, the question now is how,
especially for larger scale systems, does the TW go
about doing the chunking?
Hint: No to Forced, artifical chunking (i.e., chunking
via outlining or "poor man" modeling techniques such
as Use Cases). Yes to logical, natural partitioning.
Tony Markos
--- Bill Swallow <techcommdood -at- gmail -dot- com> wrote:
LOL! Too true!
The key is to really break your scoping down to
finite tasks...feature by feature, aspect by aspect.
The documentation effort for just one feature can be
broken down into many sub-tasks. The more specific you
are in your scoping, the more reasonably accurate it
will be, and you'll be able to definitively show the
big chunks of work to others, and perhaps get the
clarification you need to trim your estimates down or
beef them up, as needed. But Gene's right, there's
no golden formula. The developer to writer ratio is a
useless metric(and I use the term 'metric' here
loosely)... it's a
ballpark, and is only good if you're playing the right
game for the park. Same goes for pages per day.
>
> On 12/27/05, Gene Kim-Eng <techwr -at- genek -dot- com> wrote:
> > The best tool for estimating is your own past
> experience with similar
> > projects. While it is possible to come up with
> reasonable numbers
> > for some hands-on production phases of
> documentation, most generic
> > "rule of thumb" guidelines I have seen for
> estimating documentation
> > resources per hundred pages or per developer are
> about as accurate
> > as a contract bid from Halliburton.
>
>
__________________________________
Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-