Software estimation is difficult.
At Dynamics GP Land Steve Endow writes about the 30% rule while preparing estimates for Custom Software Development. He talks about how while estimating, its generally a good idea to add 30% extra time to account for risks, changing requirements and overheads. Steve has found this to be practically useful while reviewing budget to actual.
The most interesting thing for me from the post is Steve's point about how often making an accurate estimate means you end up being less competitive compared to firms that are bidding low.
"By presenting a realistic estimate that reflects the likely total cost of the project, you run the risk of giving people sticker shock. Salespeople want to sell the solution at a "competitive" price, which is almost always lower than your estimate. And then there are clients who see the total hours and assess that the estimate is "too high", or simply too expensive for them, killing the project. And if you are bidding against a firm that can't estimate accurately, does not provide a realistic estimate, or simply underbids, your estimate will look much too high, even if it is accurate, thereby damaging your credibility and trust with the client."
Estimation for software projects is a extensive subject in itself. There's a great book by one of my favorite authors, Steve McConnell on this subject - Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
Something I learnt from the book was how bad majority of us are at making good estimates. Go ahead and take a quick 5-10 minute quiz from the book to find out how good you are at estimation.
It might be an eye-opener.