OSS Consulting tols

Jared jared at hatwhite.com
Tue Apr 12 14:23:32 CDT 2005


> From: Frank Wiles <frank at wiles.org>
> 
> 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
>  ---------------------------------

The previous is all good, experienced advice. The original
question is for a Blue Book of Quotes for Software Development,
but I really cannot imagine such a thing, since software development
has so many variables. The feller who codes it in 30 hours might
do a better job than the one who does it in 10 hours, and there
really is no way to calculate all of that.

Are you creating software from scratch? Or modifying and extending
existing code? Does the customer need strong separation of code from
layout, or is this a one-off job that will need little modification
in the future; ie do you need a templating system? Will you work
with an existing CMS as your platform, or build your own security
modules? What are your existing code snippet libraries like? All
of these can strongly affect the time you need.

Quality, detailed requirements definition will isolate your costs
to a measurable level. Break it down into a dozen (or a hundred)
smaller tasks and put smaller time estimates beside each one...
making sure to specify what you won't do, when you can, so that you
have a handle on scope creep.

I think if you got some requirements together with your estimates
of hours and posted it to the list, other developers could give
you a second opinion, that might be one way to answer your question.

Let me know if you turn up with such a Blue Book.

-Jared



More information about the Kclug mailing list