6 ms·

Ask HN: How do you estimate hours required for projects

12 points by _RPM 13y ago

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?

notwedtm 13y ago
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.
Ryel 13y ago
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 13y ago
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.
logn 13y ago
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.
cshipley 13y ago
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.
lifeisstillgood 13y ago
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.
iamthepieman 13y ago
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 13y ago
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.
ruben_varnish 13y ago
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!

12 points by _RPM 13y ago

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?

notwedtm 13y ago

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.

Ryel 13y ago

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 13y ago

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.

logn 13y ago

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.

cshipley 13y ago

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.

lifeisstillgood 13y ago

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.

iamthepieman 13y ago

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 13y ago

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.

ruben_varnish 13y ago

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!