

Ask HN: How do you estimate hours required for projects - _RPM

Is there a de-facto standard formula that can be used to calculate how long it will take to complete a web application project for clients?
======
cshipley
The old de-facto formula was to estimate the number of hours then multiply
times two.

Basically, break it into pieces. Usually individual pages and estimate each
based on prior experience. Add to it other things you may need to do like
designing a schema, interfacing with other APIs, etc. This will probably give
you your best case scenario. Then multiply times two because stuff always
comes up that you didn't think about. This is what I use for "ballpark"
estimates.

This is definately open to optimization.

I think it is important to understand "both sides". Clients usually like
fixed-bid or per project pricing because it limits their risk. That way they
won't be surprised by a huge bill.

As a freelance developer, I disklike fixed bids because it requires me to
manage scope really carefully, otherwise my effective rate falls really
quickly. So this really means that I need to increase my bid by some amount (I
do 25%) do limit my exposure. So this isn't quite as good for the client as it
might look on the surface.

A better way to do it is a lesser rate, such as hourly or weekly, and then
break the work into iterations or phases, each resulting in something
demonstrable so they can see what they are getting for their money. After they
pay for the phase, they can walk with the source code written so far if they
want. This limits risk on both sides. I've gotten paid for what I've done so
far, and they have something tangible for what they've paid so far.

I start out with prototypes/proofs of concept to explore the most risky
aspects of the application first and then feed what I find back into the
estimate. This way, I can the client can know sooner than later about gotchas
that can affect schedule or cost.

------
Ryel
Yes. Pick a random number 1-10 and then multiply it by 4, and then by the
number of self-titled "founders" in the startup hiring you. That's the number
of hours it will take to finish after each founder has complain and asked you
to change something.

But seriously, most guys who can predict hours needed with any amount of
reliability are the guys who have been doing it for awhile and have already
done a similar job. They use past experience to predict amount of work hours
needed to finish something. If you truly have no idea how long it will take
you, you could begin by breaking up the project into each piece and try to
project how much time each of those pieces would take. For example, how long
will the design take, the homepage, the about page, the forms. Break each
feature apart and try to estimate time for each, then add them up.

My best suggestion is just to overshoot your hours. If they accept the offer
you should work hard to make sure you meet the deadline and if you go under
the deadline, be honest and tell them how much money you saved them.

------
8bithero
Right now this is a bit of a problem for me too. I just guestimate based on
previous work and hope nothing goes wrong or nothing unexpected crops up. In
the event where it's something I've never worked on before, I do a bit of
research and try gauge the difficulty by seeing how hard the subject is, how
many resources are available (tutorials, articles etc) and my estimate here is
compared with how long it took me to learn something similar.

I have noticed that my estimates are becoming more accurate over time but I'd
also like to know if people have some sort of a procedure/workflow that they
follow.

Another approach I experimented with was using the scrum methodology. I tried
breaking the tasks up into smaller chunks (user stories) and then valuing the
effort/time required for the individual parts before adding the values up.

------
ruben_varnish
Make a qualified guess based on previous experience and realistic numbers.

Run it through your peers (specially anyone else involved in delivering it).
Listen to the most pessimistic ones, rather than the über optimistic.

Multiply that estimation you have now by π.

Believe me, you will more often than not correct with such a calculation.

Bonus: You will be right by more or less ~10% which you can either give as a
discount to your client, or you can charge them 10% extra in the end.

Warn them that there is ALWAYS risk when estimating, and all risk should be
shared. Win Win FTW!

------
logn
I have been doing ok on estimates lately. The trick I use is to break
everything into tasks <= 4 hours, ideally 3. In fact, I much prefer 3 because
with 4 hour tasks it's too easy to think almost anything will take a half day.
That keeps things realistic and errors in your estimates from snowballing.
Also, I rarely find any tasks to take less than one hour.

------
iamthepieman
I give my best guess based on nothing going wrong. I then tell the person
asking for the estimate that things will go wrong (usually external
dependencies like getting access to the customer network or having the design
delivered on time with no changes to it) and that this will double my initial
estimate.

------
atrilumen
An old _construction_ contractor once told me that the proper way to estimate
is to "take a wild guess, and then double it... and then triple it".

Even with a lot of experience, the only thing that's really certain is that
unexpected things tend to jump out and eat your budget.

------
notwedtm
I will generally base my estimates off prior projects that are similar in
nature. If the project is unique enough, I usually push for a weekly rate
instead of a project rate. I really dislike scope creep, and this allows me to
charge for it.

------
lifeisstillgood
Don't - break into smaller and smaller tasks till writing out the task feels
like the next step is pseudo code. Then it's small enough that you can count
up the tasks and have a good idea of how much there is to do

Fibonacci, elephants and mice do not come into it.

plan carefully. If you don't know enough to plan carefully, prototype, then
plan.

