OSS Consulting tols

[Frank Wiles]

On Mon, 11 Apr 2005 15:12:47 -0700 (PDT)
Jack <quiet_celt at yahoo.com> wrote:

> Anyione know of any OSS consulting tools for
> estimating software projects?
> Or anyone have any tips on how to estimate hours for a
> php/mysql project? LAMP project?
> I have a consulting gig and could use any tips in
> calculating different tasks. I not had to estimate
> hours for PHP or mysql before and am a bit out of my
> depth on time to code and fix. Analysis, design,
> testing, etc I can probably handle.

  You won't find a good tool for this. The main reason is it would
  differ greatly between a PHP/MySQL project, a Java/Oracle project,
  and a mod_perl/PostgreSQL project.  Not to mention skill and speed
  of the coder, existance of home grown libraries, professionalism,
  good coding practices vs spaghetti code, etc, etc, etc.

  What might take me 30 hours could take you 3 or vice versa. 

  What I usually do is figure out how long my last project took and 
  estimate the size difference between the two.  But then again I
  don't bill by hour anymore, it's just not in anyone's best interests.

  Another trick is to guess on hours based on number of different pages
  and number of database tables involved. But then again, it really 
  comes down to how you write software.  Only you can truly estimate
  how long it's going to take you.

  What I would suggest is write a very very very detailed requirements
  document with the customer that spells out exactly what is to be
  built.   Not just "Will store customer infromation", but "Will
  store any number of possible phone numbers for the customer including
  area code and with the ability to store Extenstion numbers for
  office numbers.  There is no need to store country code information
  as all customers will be in the United States". 

  Then, estimate what the project is worth the client, weigh in how
  much of your time you estimate it will take, and bid somewhere in
  the middle.  

  If it's worth X to the customer and you think it will take Y hours
  to build which works out (at your typical hourly rate ) to be Z
  dollars.  The bid should be somewhere in the middle of X and Z.  

  For example, let's say X is $5,000.  Based on your normal hourly
  rate you would guess this should cost $3,000.  Make the bid $4,000.
  Not an "estimate of $4,000",  but a "This will cost you $4,000". 
  This gives you some wiggle room for your time if things take longer
  than you expected. 

  This is more fair to both you and the customer, but is sometimes hard
  to swallow and hard to sell. The trick is to get detailed enough in
  your requirements so you don't get screwed on mid-stream changes. And
  you have to stick by your guns that any significant midstream changes
  result in the cost going up.  
 
  With this system you are covered for any small changes or time 
  estimate inaccuracies and the customer is covered because they
  have a fixed cost.  Is it the customer's fault you screwed up
  half way through and had to spend 20 extra hours? No, that's your
  fault and it shouldn't be billed to the customer, etc, etc, etc. 

 ---------------------------------
   Frank Wiles <frank at wiles.org>
   http://www.wiles.org
 ---------------------------------