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.
Ron Sering asked about estimating time for a project.
Not having any better sense, I might as well jump in
The standard figure I too have heard the most is eight
hours per page. However, as we all know, that's fairly
unrealistic in the real world. When I interviewed for
this job a few years ago, I was being questioned by
the CEO (we were very small). He held up a manual of
approximately 200 pages and asked how long it would
take me to write it. I replied, "Well, the industry
standard answer is eight hours per page." He laughed
(sort of) and said, "We don't have that kind of time
to produce a manual!" To which I responded, "That's
why the real-world answer is 'When is it due? That's
when it'll be ready.'"
In some respects it's a sad truth that few of us have
the luxury of the time really needed to produce what
we have to produce. We have deadlines driven by factors
far afield from the writing process (e.g. market
windows, customer expectations, sales' promises,
development time, etc.). In order to make these imposed
deadlines, we have to cut corners in our process. We
all juggle the Big Three: cost, time, quality. The
rule of thumb is that you can have the best of any
two of them at one time, but never all three. For
instance, you can have it in a short time, and be
of high quality, but it will cost. Or, you can have
it cheap and fast, but the quality won't be very
good, and so on.
These points apply mostly to captive jobs where the
deadline is more often imposed than as a contractor
where you're asked, "When can you have it done?"
But even then you have to get some idea of what the
customers requirements and expectations are, and they
will drive the deadline you set.
I guess the bottom line is to take the approach of
finding out when it's needed and being realistic about
what you can do in that time.
EPIC Design Technology, Inc.
e-mail fisher -at- epic -dot- com