Remember, for any project -- software or otherwise -- in any business, the business is going to need to know the answers to two key questions:
* When is it going to be done?
* How much is it going to cost?
You should therefore estimate in units of time because you will be held accountable for time. (And time is money.) This is straightforward if you break the work down into components of manageable size beforehand and prepare a bill of materials itemizing each component that the final product will require. Using the BOM approach means that completion progress for the system as a whole can be tracked in terms of which materials are complete and ready to go, not just a number or percentage of how complete someone thinks it is.
Now what if your team gives one set of estimates and the estimates are off? Well, what managers have found is that usually there's a pretty consistent ratio between the time a programmer estimates a certain task will take vs. the time it takes them to actually perform a task. Therefore, the correct way to go about time accounting is, for each task, the developer should give a time estimate before starting the task and record the time it actually took them to complete it when they are finished. The ratio between the two, as it stabilizes over time, will give project management increasingly good information about how long it will actually take a given developer to do a given task, based on their estimate, and enable them to calculate schedules accordingly.
* When is it going to be done?
* How much is it going to cost?
You should therefore estimate in units of time because you will be held accountable for time. (And time is money.) This is straightforward if you break the work down into components of manageable size beforehand and prepare a bill of materials itemizing each component that the final product will require. Using the BOM approach means that completion progress for the system as a whole can be tracked in terms of which materials are complete and ready to go, not just a number or percentage of how complete someone thinks it is.
Now what if your team gives one set of estimates and the estimates are off? Well, what managers have found is that usually there's a pretty consistent ratio between the time a programmer estimates a certain task will take vs. the time it takes them to actually perform a task. Therefore, the correct way to go about time accounting is, for each task, the developer should give a time estimate before starting the task and record the time it actually took them to complete it when they are finished. The ratio between the two, as it stabilizes over time, will give project management increasingly good information about how long it will actually take a given developer to do a given task, based on their estimate, and enable them to calculate schedules accordingly.