

What I learned from working with my first client - RandallBrown
http://fredandrandall.com/blog/2011/04/30/what-i-learned-from-working-with-my-first-client/

======
thinkingeric
"Then I added a little padding time because everything always takes longer
than expected."

If you are implementing something which is almost exactly like something you
personally have implemented before, then your estimate will be almost exact
because you should have tracked how much time you spent on the original ...
and assuming that too was a re-implementation of something you'd already done
the R&D on. IOW, this is at least your third time.

If you are implementing something for which you have references that are very
close to what you are building (but you didn't build it) and you already
understand them, then you can make a reasonable estimate of the time to
implement. In this case the OP's advice works .... add some padding. The more
granular your breakdown of the problem, the better you estimate will be.

But when there is R&D on the problem, you are not talking about 'padding', but
'factors'. If you are doing something that is new to you, but you think you
have (or can find) decent references, then you can estimate based on how you
hope it will go (based on your breakdown of the problem), and multiply by 2.

If you can't find references, then factors of 3 or 4 beyond your ideal
development scenario will be more realistic.

It's worth noting that if you are in the last scenario, then you probably
weren't a good choice for the project. Also, 'agile' pricing would be better,
but either fixed pricing or giving clients some idea of what to budget is more
typical.

------
superkarn
Like many things, knowing what you're worth (how much you should charge) and
estimating project time take practice. The more you do it, the better you get
(hopefully).

------
murz
> You suck at estimating!

Took me a while to learn that one, but it's so true.

