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: Scoping a Product Was RE: complete documentation
Subject:Re: Scoping a Product Was RE: complete documentation From:"CB Casper" <knowone -at- surfy -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sun, 15 Jan 2006 11:17:15 -0800
>> Since, evidently, there is no published tech writer
literature on the scoping a product, we should follow
the lead of the communities that have written about it
- the Requirements Analysts and (real) Systems
Analysts. Tony Markos >>
To which I finally respond:
The only way to scope any project, and this is a
definitive, meant to exclude any possible, potential,
past used, or even unmentioned methodology or analysis
path, is to do the following:
Figure out what is included and what is not.
You can use this and create a whole industry around it.
Every project is unique and requires some thought as
to what can be done, needs to be done, and what
should be done within the boundaries of time, budget,
and quality.
Most projects can build on the knowledge and
experience of previous similar projects, so rarely
is a project cut from whole cloth, warranting a new
and totally virgin scope.
Many times the scope is determined before any real
tangible work is done on the project. The scope
determines everything else. Scope is such a broad
term and is used differently at different phases,
that it is impossible to describe it definitively
for all cases, except by using blurb above based in
the context it is used.
My project plans always include a table of what the
project is and is not, and sometimes a maybe column
for things that might be included depending on time
and opportunity.
The scope of my documentation is dependent on the
scope of the product, which is determined by the
scope of the corporate division, which is also
forced within the scope of the company as a whole.
Context is everything, and without it, not much
can be written, again, except for the blurb above.
CB - who usually doesn't make such narrow
pronouncements about the veracity of any particular
approach, but thought this time the subject of
scope could use my vastly superior insights
-- http://www.surfy.net for Free Email <br> http://www.ergova.com for Low Prices on Hotels, Books, and more.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-