

Ask HN: How do you estimate time for a project - 9ec4c12949a4f3

When you are looking at a body of work to complete, something as simple as "I need a database to store info, needs some inputs and reporting, backups, and other generic stuff," or even otherwise, how do you go about deciding how much the project will cost, how long it will take, and other related resources consumed?
======
frossie
At the risk of being stripped of my PMI membership for sloppiness, I have a
rule of thumb for estimating tasks when (a) I don't need to be accurate and/or
(b) I don't want to take the time to be more accurate.

A. geek estimate "couple of days" -> two weeks

B. geek estimate "couple of weeks" -> two months

C. geek estimate "couple of moths" -> six months

I don't mean that in a nasty way. The "geek" or technical estimate does indeed
take that time - for example the core technical work in the first example does
get done in a couple of days in the zone. But there are complications, there's
polishing off, there's testing/scaling/deployment/troubleshooting and, unless
you are very very lucky, there are other things to do.

Of course there is a significant error in such rough binning, but it comes out
in the wash over the life of a project.

Anyway I would say your example is a type B if you are starting from scratch
and lack the necessary know how, or type A if this is something you have done
before.

~~~
thisisananth
I don't know if I am a geek exactly, but by experience I can vouch for it and
the reason is exactly that I will tell only time to make the feature work,
without estimating for the polishing and testing.

------
adolfojp
Q. How do you estimate time for a project

A. Very badly

------
Ramone
This is such a huge question, but the 3 things that have helped me most:

(0) Make sure you are clear on your requirements, and spend the time to do the
research/prototype if you're not. Estimates have no hope in being right if you
don't know exactly what you're going to do.

(1) Break tasks up to pieces no bigger than a day's worth of work. You do this
because the larger an estimate is, the larger the margin of error on that
estimate is. That's the reason that the standard "multiply-by-three" rule that
many people say doesn't work.

(2) Document your tasks and estimates so you can refer to them when making new
estimates. Otherwise, you don't learn, and you don't get better. My team
really does this, and it really works. We order the historical tasks by the
actual time-taken and estimate new tasks by fitting them in that ordering.

Keep in mind though that it's probably _more_ important to the people that
care about those estimates that you're constantly updating them on the real
situation. In many scenarios it's better to be a little late while providing
high-quality work VS. being on time and providing crap. To pull that off, you
have to find ways to constantly report your status/progress and get that
external trust.

EDIT: Added point 0 after further thought about my team's worst pain-points.

------
Keyframe
I use a simple formula for pricing - what I make times four:

\- 1/4 what I make

\- 1/4 equipment and software cost and amortization

\- 1/4 corporate profit (I have a company setup)

\- 1/4 corporate cost overhead + corporate tax

so if I make $100 per hour - total cost is $400 + VAT per hour. Cost per my
hour is the variable here - because some things are more expensive than
others. 3D VFX costs up to $400 per hour, while a simple coding session or a
gfx session might be $50. Thus it can vary from $200 to $1600 per actual
working hour. It depends on the complexity of the task. Also, after a certain
threshold of needed working hours I tend to switch to a billable day unit vs
hours. Other things like if I need to go on location/set etc. play an
additional role.

same goes for time needed, but in more loose terms: Whatever I think it will
take times four - and most of the time that estimate turns out to be right
(sometimes due to me, sometimes due to client).

But that is just me, over the years I found out that this metrics works best
for me.

~~~
vgurgov
After reading some 208 words that it took you to reply that q, i still didnt
get how do you actually estimate time that it will take you to do some prjct.

You reply can be pretty much summarized as: "I have overpriced hourly-based
model" which is 202 words less than what you wrote.

~~~
Keyframe
Where did I say anything about overpriced model? Being smug doesn't help you.
Prices are what they are because market dictates them like so. VFX Supervision
costs roughly $3000-$5000 USD per session of roughly 2-4 hours. That is the
standard rate. Price has its reasons why it is so high, not one of those is
"because I say so". If you work on web sites for a client for $50, that
doesn't mean it is a standard rate everybody else bills.

To address your second point, which was inferred in the text. Calculating time
needed is, in my case, always based on experience. My experience, in my line
of work, is pretty much in line with others in the field. For a trivial
example, if you know that doing a 'flying logo' shot of 15 seconds takes you 2
hours to create from provided materials - you multiply that by 4 to give an
estimate to your client. Because there will be revisions which eat time. In
the end, I am rarely at the estimated amount because I have a safe buffer of
X4, so client never gets screwed by getting a wrong estimate. It's better to
overshoot an estimate than undershoot it. Because client can budget
accordingly both time and money, which is really important in VFX. In the end
client will get billed at that amount or less, or overshoot budget due to
complications on his end.

------
brudgers
Estimating how long something takes requires experience.

The only way to gain that experience is to start estimating and then seeing
how accurate your estimates were.

Also there are are two types of time: clock and calendar.

A good fee accounts for both (at least in a small business).

A 100 hour project doesn't necessarily take ten days or two and a half weeks.

It might take three months or longer based on client review times, other
projects in the pipeline, and just letting your ideas percolate.

Calendar time is more critical than clock time for a business because it
determines cash flow.

If you can bang out a $20,000 project in three weeks, do you really care if it
takes 14-18 hour days?

If a project throws off $3500 a month for six months, how much does it matter
if it takes 25 hours vs 40?

Personally, I hate keeping track of hours. I find half-days a meaningful unit
of work...it allows for distractions.

------
donohoe
First of all your example is not necessarily simple. It might be, but you
don't know that yet.

I would draw up a list of Requirements. It would outline what is, and what is
not, in scope. That takes time in itself and you should run it by the client
and expand on what each point means. This will allow you to determine anything
that can be removed, or needs to be added (and to just understand the project
better too).

After that you can use it as the basis of _an initial rough estimate_.

When you have an idea of how much time it will take, add 30%.

~~~
ams6110
This touches on a question I have been chewing on. I've recently started doing
contract work. I'm not doing code-monkey contracting; my projects have all
required some requirements analysis and design outlines before a reasonable
estimate is even possible. Do you normally bill for that kind of work? On the
one had it feels wrong to have a client ask for an estimate and then bill him
for 10-20 hours of work, on the other hand that's 10-20 hours I could have
been billing another job (in theory, anyway).

~~~
9ec4c12949a4f3
If you're competing for a contract I wouldn't, but otherwise I would do a
basic design phase and then charge them during the advanced stages of design
"to get all the details right" (if you're in a fortune 500 company you can
probably retire off the bickering between managers over one HTML page)

------
bediger
Unfortunately, the mathematics points to "you need good judgement":
<http://www.idiom.com/~zilla/Work/Softestim/softestim.html>

At the very least, large limits exist as to how accurately one can estimate
this sort of thing.

------
keefe
Like other posters said, it's a generally difficult problem.

I would break the problem down into subsections and estimate each, depending
on my experience.

e.g. database setup and connectivity - one day +/- one day, I do that all the
time. graphic design of final site... 4 weeks +/- 4 weeks.

------
weaksauce
My rule of thumb is:

((Time Estimated as worst case * 2) * 130%) = close to true most times. I
would say it's a normal distribution with a smallish variance.

worst case I can do that in a week ==> (1 Week * 2)*130% = 14days + 4.2days =
18.2 days give or take. Usually pretty accurate.

~~~
ams6110
How long as this been your rule? Do you not find that you unconsciously
improve your worst case estimates and your buffer for unknowns becomes
excessive?

~~~
weaksauce
It's been a while. no I find that as a programmer we tend to be overly
optimistic on things and do not take into consideration the other things that
need to be done. For example, the cost of meetings, underestimating the scope
of the problem, and the little snags that eat up time. An example of a little
snag is trying to get some library or program that you need to continue
installed and configured correctly. This takes more time that you expect it
to.

------
Sukotto
I generally follow Fred Brook's estimation law: it will take at least 9 times
as long as the time needed to hack something together for me to use once.

I forget which chapter of Mythical Man Month that's from and unfortunately
don't have access to it right this second to check.

------
bmelton
Reading through the replies, the generic answer tends to be 'overestimate' or
'multiply the time you think by x', and honestly, those aren't bad answers.

Getting a feel for estimation is the hardest part of consulting, and it gets
worse, as every customer is different. I've had customers who came in WAY
under deadline (which is a problem, because it means I have empty calendar
days and am not getting paid), and I've had customers in came in WAY over
deadline (which is a problem, because it means I'm pushing back other
obligations or start dates.) I tend to average somewhere around 'on time', but
there's no magic bullet for it, and even if there was, the customer would
likely either eat/break/object to your use of a magic bullet, or expect
receive ownership of said bullet at the project's completion.

In the mechanical industry, this is mitigated by extensive knowledge of how
long things take, and on averaging. If I call the local Jeep dealership, and
ask how much it will cost to replace my transmission, they have a database
they look in, which is effectively an average of how long transmission
replacements have taken over the history of however long they've been
replacing transmissions. They know the material cost, and they have a good
average on the labor time (and of course they know the labor rate). They have
_experience_ in estimating that sort of work -- without it, their system would
be largely useless.

Aside from that, until you get that experience, the best advice is the oft-
submitted (multiply by 'x'), and make x as generous as you think you can get
away with until you get some more estimating experience under your belt.

------
gojomo
It takes 3 months.

------
9ec4c12949a4f3
Here's what I have done for my most recent project, I have abstracted work
units of any generic project and drilled down into probably components.

I have taken three major groups: System, testing, support. Each of these will
change the timeline and cost of the project. Support is an after-delivery
agreement, they may want testing, or run into problems that I have the answer
for. This is also the cost of producing the manual.

There is testing, I estimate this system should be tested over 5 days with
different stresses.

The system is broken into hardware and software groups. Hardware expenses are
quite obvious: networking, connecting devices, the server/machine it runs on.
Your needs may be greater if you are in the hardware world, but all
professional projects I'm involved in are software-based.

The software is broken into the OS configuration, tools related to the
platform (like setting up Apache), and the application we are creating. The
application will be composed of logic and storage.

The logic will require specific things such as a framework, a UI, system
inputs, and debugging. The storage exists of either a DB design, a flat file
design, and any reporting requirements.

I found it best to draw the above as a hierarchy. I then estimate time for
each seperate component, and if there's something I don't know how to estimate
I need to clear it up.

The difference? My "geek estimate" (as posted by frossie) was about two weeks,
and after doing this above method, it actually is looking like 2 months and 2
weeks of time. I built the time requirements using a gantt chart.

