Re: Scoping a DocumentationProject??

[John Garison <john -at- garisons -dot- com>]

In my experience, this is often first done in a hallway conversation 
with the person who wants the scope for some sort of project 
requirements document. I try to get a very basic understanding of the 
project - how extensive is it, how many programmers are working on it, 
do they have a spec - and find out who the product champion is (the 
person who has the most to lose or gain by its success). Then I read 
what I can get and talk to as many people as I can find out are working 
on it. My goal in the conversation is to discover what is currently 
"known" about the project, what is assumed, what is hoped for and 
desired. Then I spend some time (gasp!) thinking. Then I decide based on 
my experience with the people involved (things like "Can they say 'No' 
and mean it" enter into my thought process), similar projects (new 
technology or something well understood), similar sized projects, what 
we currently have I can borrow or outright steal, and make my 
determinations based on that. As you can see, it's a non-scientific 
personal process. You can't teach experience.

And I'm usually pretty darn accurate about what needs to be developed, 
how long it will take, and what the final results will look like.


John Garison


Tony Markos wrote: