Or "How to Make your Project Manager Love You..."

When I was getting started in software development, our team always estimated in terms of days or weeks.  We'd have a task like "build the importer component" and we'd each say "oh, that's two weeks worth of work."

We hadn't fully defined what the "importer component" was. We didn't know how it fit together with the other tasks.  We didn't know what all the little pieces, tasks, and details that came together to make the task.  To be painfully blunt:

We were clueless.

Somewhere along the way, I read Joel Spolsky's "Painless Software Schedules" and realized I was doing something horribly wrong.  Worse, after I joined the dotProject team - and later web2project - I realized something even more interesting:

Estimating a big task is painful... and will be wrong 135.7% of the time.

There are just too many variables to consider to come up with anything useful.  As I touched on in my recent PHP Advent article, the key is to break things down into smaller tasks.  And break those into smaller tasks.  You may even need to break things down into the individual todo list level, it doesn't matter.  The key is to get things down to a level where you can stick a specific time estimate on it.  My rule of thumb is any task bigger than 4 hours should be broken down further... and a range of time (eg 3-4 hours) is perfectly acceptable.

Now that you have this massive list of tasks, an estimate for each tasks, simply add all of them.  You'll end up with a number where - even if it's the same as your original estimate - you can now track the task to a finer level of detail as you work.

Your estimate is more likely to be accurate and you can track and catch delays and bad estimates before they put the project at risk.