> While true, it's also true that most times (IME at least) the boss doesn't 
> want to wait that long. In particular, the boss doesn't want to spend the 
> time it takes to describe out all the details to the point where you could 
> give an accurate estimate before he has an estimate he can rely on.

Well of course if you think your project is only going to take 1-2 months to 
complete you are not going to spend 3 weeks planning it :-)  I don't know 
what a good ratio is, but I would imagine someone has researched this and 
written about it somewhere.  It will also depend on how similar your 
projects are to previous ones, obviously if they are pretty similar you 
won't have to spend much time to get a very accurate estimate.

> If you look at (for example) function point analysis, it requires that you 
> know every field of every table in the database, every column of every 
> report, every input to every entry form, what the equation is to calculate 
> any derived information, and a few other things like that. By the time 
> you've figured out an entire business system to this degree of precision, 
> you might as well just code the damn thing.

Well yes, that seems a little over the top for simply getting an estimate of 
the time needed to design and implement the thing.  It's like me saying that 
I should document every single detail needed on every mechanical part and 
how long it will take me to design it, of course it's quicker then to just 
actually do the work!

> Which is not to say my bosses aren't foolish, but clearly "design it all 
> and we'll tell you" doesn't work in most situations. Especially when the 
> requirements change faster than you can code them.

In our business the requirements change way quicker than we can implement 
them, it's always a case of going back to the customer and saying "ok this 
change will delay the schedule by X weeks and cost you Y".  Then there is 
usually some negotiation and we come to an agreement of what to do.

Post a reply to this message