On Mon, 11 Apr 2005 15:12:47 -0700 (PDT) Jack [email protected] 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 [email protected] http://www.wiles.org ---------------------------------