The thing that has helped us improve our estimates is not directly related to accurate time tracking, but has been utilizing the agile processes of two week iterations and "planning poker". We use planning poker to estimate each issue we assign to an iteration. You can google it for further details. The basic idea is each team member flashes a card at the same time and that is their estimate for how long the issue will take. Making everyone flash the card at the same time is important as it prevents junior developers from waiting to see what the senior people say. If there are major discrepancies we then discuss them and re-estimate.
The unit we use to estimate is an "ideal day". This is not a concreate unit, but a concept. It is defined as how much work could you get done in one day of coding with no interruptions. This may or may not really equate to a calendar day, but in the long run it doesn't matter. After a few iterations your project will develop a certain velocity you can track and you'll know roughly how much work you can get done in two weeks.
If you don't want to adopt these sort of development processes another thing we have found that works well is the concept of "information radiators". Basically you just have a TV or computer monitor in a common area displaying various metrics related to the project that you want to improve. You have to be careful with this in the sense that you can't use the metrics in a punitive manner and you want to structure them so that if the developers game the metrics the result will be positive. Not using the metrics for raises, bonuses, etc. will decrease the likely hood that the metrics will be gamed, but structuring them correctly can eliminate the concern entirely.
It seems when people just see these metrics day to day there is some unspoken human need to improve them. Similar to how some people seek badges in forums such as this!
