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.
Re: Estimation of Timelines for Documentation Projects
Subject:Re: Estimation of Timelines for Documentation Projects From:Goober Writer <gooberwriter -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 6 Oct 2003 08:38:45 -0700 (PDT)
> As a set-in-stone projection of when the project
> will be completed, perhaps it
> is a bad idea. But how else are you going to judge
> how long a project is going to take.
You can scope using numbers you know work, but you
can't blanket assign numbers the same way across a
variety of projects. If you set X pages/Y hours, that
might be valid for printed user guides but maybe not
for online API references.
> And I say perhaps because it depends on how long
> you've been tracking your
> productivity. If you've been tracking productivity
> for a good period of time
> your average "page" includes simple and complex
> topics lightly to fully
> researched and explained. This mix of "pages" will
> be the same as an average
> project. So, the productivity study should produce
> very accurate estimates.
This assumes that projects will not vary from the
types performed in the past, which at least I am
finding is not the case as we travel further into the
21st century.
> The danger is in not following productivity in the
> current project to identify
> if the project is more complex than usual/average
> requiring a revision in the estimates.
That is always a real danger, but another real danger
is a very misrepresented number on how long something
is projected to take. Why? Because another real danger
is other departments assuming an arbitrary buffer of x
weeks before/after the project and running with the
latest date for other contingent deliverables.
Yes, many factors and many dangers, so the more care
that's put into scoping nd planning at the onset, the
better. By using arbitrary values to scope a project,
you're opening your project up to more danger
variables than if you took the time to specifically
address the project using specific weighting criteria.
=====
Goober Writer
(because life is too short to be inept)
"As soon as you hear the phrase "studies show",
immediately put a hand on your wallet and cover your groin."
-- Geoff Hart
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
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 view a live demo at: http://www.ehelp.com/techwr-l3
---
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.
