Re: Scoping a DocumentationProject??

Subject: Re: Scoping a DocumentationProject??
From: Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>
Date: Thu, 05 Jan 2006 07:25:41 -0500

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.

Tony Markos wrote:

Bonnie Granat stated:

They [developers] create software or software plans,
you document [using their software or plan as your
input]. You cannot "scope" out a documentation project
for something that doesn't exist yet unless you talk
to the developers or look at firm plans for the

Tony Markos responds:

If the TW is working pre-development on, for example,
a requirements spec, it has been my experience that
most often the TW is not simply given a scope
statement with the required degree of rigor. Frankly
Bonnie, I usually get a disjointed mess called a plan
of some sort and I am charged with creating a
smooth-flowing user-friendly requirement doc.
To create such a doc in such situations, the TW has to
draw the scope out of the developers. And, for
larger-scale systems, a fairly rigorous and formal
process seems to be required. It is this process of
proding the developers (and/or SMEs) that I am asking

Beth Agnew
Professor, Technical Communication
Seneca College of Applied Arts & Technology
Toronto, ON 416.491.5050 x3133


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!

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.

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

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 for more resources and info.

RE: Scoping a DocumentationProject??: From: Tony Markos

Previous by Author: Re: Items in a Series and Comma Use
Next by Author: Re: Scoping a DocumentationProject??
Previous by Thread: RE: Scoping a DocumentationProject??
Next by Thread: Re: Scoping a DocumentationProject??

What this post helpful? Share it with friends and colleagues:

Sponsored Ads