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.
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.
(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.
A. Very badly
- 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.
You reply can be pretty much summarized as: "I have overpriced hourly-based model" which is 202 words less than what you wrote.
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.
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.
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%.
At the very least, large limits exist as to how accurately one can estimate this sort of thing.
I forget which chapter of Mythical Man Month that's from and unfortunately don't have access to it right this second to check.
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.
((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.
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.