Four thoughts. First, define what maximum and minimum effort estimate is acceptable - for example, tasks should not take less than 2 hours or more than 4. Second, communicate that contingency shouldn't be included in the estimates so they aren't padded. Instead, have some room in the overall plan for tasks to slip. Third, measure actual vs. estimates to learn how the team estimates - you'll find that some people consistently over estimate, and some consistently under estimate. Show them and have them adjust course. Finally, make sure that the people estimating understand that no answer is acceptable - it is better to redirect a task than have wide guesses.
We just started doing this properly. To start, I think it's important to define a structure for setting expectations and estimating tasks.
We use Pivotal Tracker's linear point system and aim for a certain velocity within our teams.
On each project, we meet with everyone who will be invoked to try to estimate the efforts using that point system. As the project goes along, it's the product manager's (or head engineer's, or boss man's) job to keep track of how the team is doing to execute and either estimate the timeline or de-scope features that are low priority and can be pushed for the next release.
Your job is to lead the team into a rhythm of shipping product as fast as they can with a high quality of integrity.
Happy to chat further about this stuff we recently went through it :)
