Mark,
I think Jared and Andy both have made excellent suggestions, especially Andy's comment about breaking it down into manageable chunks.
So, what resources are recommended to consult to make great estimates? What habits to develop?
When I first started estimating projects I very often would make the mistake of only estimating my programming time, and not thinking about things like time to deploy on the servers, to update/fix/tweak the database, meetings and general communication etc. etc. Thankfully my boss was the middleman between me and the client and he would always remind me of these things and then add time to my estimate. Eventually I noticed the trend and basically wrote myself a checklist of all the "other" tasks I needed to include in my estimates.
This may seem simplistic and maybe even trivial, but since I was not experienced in estimating whole projects, so it just never even occurred to me. I suggest making such a list of yourself, not so much of "things you might forget to include", but really a list of best practices you see being done around you. Every organization is different and every line of business has it's own quirks, and the best way to learn those things is from your more experienced peers.
I know that before the good estimate comes the strong technical specification so you can know what you are estimating
Yes, this it true, but ONLY if the specification is STRONGLY adhered too. I have meet many a project manager in my days who did not properly enforce this with change orders. The spec would evolve and morph into a project very different from the one originally estimated but without any change in that estimate or schedule. The result of this was almost always total chaos and monetary loss.
The judicious use of change orders is, IMO, the hallmark of an excellent (and well seasoned) project manager.
And even if you don't issue the change order (for whatever reason), make sure the client knows that you were going to. Not so much because you want them to know they are getting something for free, but because it is important to communicate to them the change in scope and sometimes the best way to make them see that is to show them it in monetary terms.
I also wouldn't mind hearing stories about "software estimates in the real world", the good the bad and ugly.
I once had a senior project manager whose estimates were almost always the same price, we called them his $19.95 specials. We even went so far as to make him a small joke program with which he could easily break his estimates into 'n' payments of $19.95 each. It was funny at first, but soon got to be really bad. His basic technique seemed to be: come up with a price the client will accept, then shoehorn the schedule to fit that price (regardless of the actual time and materials it took).
Anyway, I hope this maybe answers some of your questions.
Steve
