This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I often ask such a question when I interview. If someone spits out "I use COCOMO" or "I use function point analysis" or any other "I use X" I'd probably see it as a negative. Anyone can spit out some textbook answer. I don't know any "good" answer to how to do estimation. A good answer to the question, IMHO, is to talk about different methods of estimation, and then to get into how to minimize the uncertainty and error in whatever process is used. Of course, just giving that answer isn't sufficent, because then I get into how they applied it, so I can catch those who simply read a website and regurgitate an answer. (Nothing personal to those reading this, and I encourage you to read here and learn, but estimation is as much an art as science, and you need to really do it to understand it.)
Can anybody advice how to do Project Estimation in a role of Project Leader, as i came across with this question many times but not able to satisfy the interviewer.
From practice, I can tell you there are two distinctly different kinds of projects.
The first is the "widget" type, where you are just making a clone of something you or the company has already done. Eg. yet another J2EE shopping cart. In this case the metrics that you collected on the other similar projects, assuming that you collected them, will give you a good estimate on the time and cost of the next similar project. This is like going to the auto mechanic for an oil change, he has no trouble giving a firm estimate.
The other is the "research" type, where you and your company have never done anything quite like this before. The cost and time to do the project can only be estimated after you have done a portion of the project. Then you may have a better idea of the level of complexity. In bureaucratic companies these kind of project are nightmares, in entrepreneurial companies they are the lifeblood of the enterprise.
These of course represent the extremes, there are plenty of shades of grey between them.
Systems like COCOMO that rely on determining the level of complexity in terms of function points or lines of code work well on the "widget" end of the spectrum, but fail completely on the "research" end.