[thelist] How do you estimate time for any given project?

Lauri Vain lauri_lists at tharapita.com
Fri Aug 29 18:05:01 CDT 2003


<tip type="Estimating time for projects">
> This question has once again passed through my office: How do you
> time for any given project? I would like to siphon your thoughts,
> or other methods you use to get an estimate.

Well, quite simple really. 

First of all you have to have a pretty good specification (Joel Spolsky
has some good pointers and the reasoning why you need one -

Then you simply sit down, break larger tasks into subtasks (in simple
words - when you have to create a not very complicated product database,
you need a script to list existing products, you need a script to
add/modify a product and you need a script to delete a product, plus you
need to create the database tables and template files for presentation)
that you have to do and estimate the time it takes you. 

Next you write the amount of time it takes you to do each task. 
For example you might do: 
** list existing products, template file - 40 minutes
** add/modify script, template file - 40 minutes
** delete script - 5 minutes
** create database table - 5 minutes

(numbers above are made up purely to have round numbers for the

That makes an hour and half. Now you multiply it with a number to also
compensate the time it will take to debug, communicate with the client,
pay the accountant's salary etc. Some people multiply it with two, some
with three, some with 1.5 etc. It really depends on you and your

You might add the company profit on top of all that or you might add the
profit when multiplying with the number above. 

Let's assume you multiply it by two. 

Now you have (2*1.5hrs=) three hours. 

You multiply it with the hourly rate set by your company for the
particular work and there you have it. 

When your client wants something significant changed that wasn't in the
original specification, you have to agree with him/her that it will be
billed additionally (out of scope work in terms of the original spec). 

At the same time you have to give YOURSELF enough flexibility to make
sure that your spec doesn't make you do stupid things. For example you
(or the project manager) might agree in the beginning that there will be
a lion's roar everytime somebody hovers over a link (ok, I'm pushing it,
but you get the idea). Then, later, you sit down with the client and
convince them that it's not such a good idea after all and he agrees. 

When it's time to close the project, however, he takes the original spec
and says "there isn't a lion's roar, there isn't this and that neither".
That's the sentence that means that you're in trouble (they might demand
reduction of the fee or additional features or implementing the stupid
stuff - lion's roars etc). All the stupid stuff would have taken 5
minutes, but that doesn't satisfy the client - he didn't get what you
originally agreed upon. This is quite common with small, medium-sized
and larger projects (won't usually happen with tiny projects). 

The only way out is that you have to constantly update your
specification and add a disclaimer stating that "the specification is
work in progress and subject to change when needed". (Joel also has some
great articles on the subject - "Painsless Software Specifications" is
what he called the articles, I think.) Also, you have to make sure that
*everybody* (you, the entire team... and perhaps most importantly - the

Estimating your time correctly comes with time. 

The method of estimating time can, at times, be a bit rough. But boy,
you should see how they estimate the initial price of a log house that
will be built after client's the drawings :) 


More information about the thelist mailing list