Duration of a task

An often overlooked but important question is 'How Long should a project task be?'. The simple response is 'as long as it needs to be......' but wrong. Project tasks are tracked to reduce the risk of slippage - so the task duration needs to be such that it can be definitively tracked and provides soon enough feedback to allow the PM to react to if it is slipping. An extreme example is a task being the same duration of the project. 'Sure, I'll get that done by the end of the project.....' - yep, right. The right answer to the task duration question is dependent on a few things: how long is the project, how critical is the task, how much time can you afford to lose with the task such that it does not greatly impact the project delivery. The way I approach it is that a single tasks, for a mid to large size project, should not be less then 1 week or more then 2 weeks - BUT - it's all dependent on how critical the task is. If tasks of much less duration are tracked, the management aspect becomes extensive. There was one project where a team member submitted a 10,000 task project plan, with many tasks tracked down to the hour and 1/2 hour......my questions was 'what if someone burped??'. Each task needs to be for a definitive amount of work, have a definitive deliverable (not 'the task when complete will provide 80% of the functionality' - what??) - have an assigned person, etc. If the defined work is less then a week (say a day) can it be grouped and rolled into associated tasks. If a task is more then 2 weeks can it be divided into sub tasks, etc. A CRITICAL task - such as installation of software needed to go live - that takes only 3 hours, should be tracked......no need to say 'gee I guess we forgot something' during the go-live process.

There should be some more 'scientific' approach to task durations, but with the complexity of planning, defining tasks, calculating impacts/risks - I can't see a good scientific approach being as effective as a PM with experience.