Re: Scoping a DocumentationProject??

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

Scope of a project should really come from the product manager in 
conversation with development as to what will be included in the 
release. Projects go terribly wrong when neither of those parties has a 
firm grip on the scope. The TW hasn't a chance of documenting a moving 
target, let alone estimating how long it is going to take. If it's the 
techwriter drawing the scope out of the developers, the process is 
flawed and there will be nasty surprises. The people responsible for the 
scope of the project won't be vested in it enough to keep it under control.

Identifying scope, and then constraining scope during development (i.e., 
avoiding creeping elegance) is probably the single most important factor 
in management of any project. Once you know exactly what's in, and 
what's out, you can estimate fairly accurately as long as scope doesn't 
change. I always have a clause in my doc plans (and client contracts) 
that specifies any change of scope as a reason to re-estimate and 
renegotiate the project.

Ideally, the scope should follow from the requirements for the product. 
They are inherently a statement of scope, as long as people don't start 
adding features and functionality during development. Documentation 
scope then matches the requirements and specifications, with a TW spin 
to address the tasks that you identify within those specs.

I recommend that anyone who wants to learn how to scope and estimate 
projects take a good project management course. It's worthwhile to go 
through the exercise of doing the work breakdown structure, GANTT 
charts, and resource allocation.
--Beth

Tony Markos wrote: