In estimating, accurate does not mean 100% assured. After all we are estimating, not divining the future. We expect different degrees of accuracy depending on knowledge of requirements, experience with the tasks at hand, the available resources, among other factors. It is widely accepted in project management circles that early in the life of a project an acceptable estimate might have 50% or more possible variance, while later, after requirements have been well understood and transformed into a design the estimate accuracy may increase to within 10% of the final outcome (assuming that the estimators know what they are doing and the environment is stable). Nevertheless, we find that executives, sales people, clients and project sponsors pressure project managers (PMs) into making definitive estimates well before there is enough information to accurately do so. Project managers often pass the pressure along to team leads and project performers who view the whole estimating effort as a stupid game in which no one wins.
In an ideal world, we might use parametric estimating where the estimate is based on a rate that is calculated over time based on past performance. If the size of units is roughly uniform and the method being used and resources are consistent then the estimate can be highly accurate. Unfortunately, in most project environments, parametric estimating is not a realistic approach. In some environments projects are inconsistent. Computing the rate requires accurate time tracking and record keeping across multiple projects. The data has to be available, up-to-date and accessible. In addition, the estimator must know (or at least estimate) the number of units in a project to apply the rate to. This implies that there has been sufficient requirements analysis and design.
Instead of parametric estimating we find that relatively small and simple tasks or deliverables (artifacts) are estimated by performers to provide definitive estimates. For these to be accurate the estimators must know how to estimate, folding in risk and uncertainty and a solid understanding of the deliverable. These definitive estimates, as well as parametric ones, can only be made after a significant amount of time and effort has been expended on requirements definition and design.
Since most organizations require estimates early in the project life cycle, these must be based on high level assumptions about the product and other factors (resources, etc.) These are analogous estimates based on the overall nature of the project and its similarity to past projects.
Knowing these basic realities of estimating, the project manager is responsible to push back with due diligence to make sure that those who demand early definitive estimates understand the risks. It is quite possible for a senior manager to get a seasoned PM to make an early estimate or for a sales person to set expectations with a client that are unrealistic. However, the result is almost always disappointing. The impact on staff morale, the reputation of the project delivery group, the quality of the product, client relationships and the bottom line are predictable and unpleasant. Why repeat painful, unpleasant behavior? Instead, accept the reality of estimating uncertainty - the more you know, the better your estimates will be. Getting to know more means doing the work of requirements definition and design, collecting and making available useful historical data and being realistic about uncertainties such and resource availability, changes, etc. As a PM it is your responsibility to educate your team, your client, sponsor, manager and those responsible for setting client expectations so that they all understand the realities of estimating.