Good estimates come from good designs

Sergio again hit the nail. It is important to understand that estimation is not one-time, it is ongoing process - The team needs to inspect and adapt. In case you have a constant team and a discipline to do it in small iterations by this the estimation's will evolve into something we can call "good estimate".

Agree with Sergio. Good or bad estimate depends upon how much information is available at time of estimation and how team is confident.

As with most aspects of project management, tailoring, scaling and adapting practices based on a set of good principles is key. When it comes to estimation, the issue is not the range of an estimate but the commitment being made based on the confidence level place on that range. Combining estimation techniques, communicating assumptions and nailing down as many variables as can be safely nailed down can help to increase team confidence, but the reality is that till the very last day of a project we are still dealing with a probability distribution and not a certainty.

Kiron

Sergio, I hear you. In IT projects we can break the available schedule into three parts, one for design, implementation and testing. I think depending on the methodologies we use these will be called different things, but all methodologies have time dedicated to these three activities. After all schedules should be made with skepticism, not optimism.

I think an estimate need to be "good" in the context it is given.

In early stage it won't be precise, wide margin of error. The Cone of Uncertainty mention by Sergio.

To have a "good" estimate you need good input.

What you stated about divide the schedule in parts is equal to say we will have more information when we move forward into the project life cycle. Barry Bohem´s Cone of Uncertainty can show you it adding that Mr Bohem created it based on 10 years of research and statistics. Is the same I stated: estimation depends on information and time.