I have a client that is requesting that I enter in all work packages no longer than 8 hours. My experience is that 40 hours is standard but they have stated that past experience tells them that 40 hours introduces risk.
My experience tells me that having individual tasks at only the 8 hour max will introduce risk all on its own.
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
40 hours, 8 hours, 1 hour it is all artificial. Outcomes are what matter. Design tasks around incremental and measurable outcomes. This will keep people focused and connected to the project. True the shorter the time between effort and result the better. But outcomes should be the driver Saving Changes...
I agree, any yardstick you use is artificial. As a general rule, I believe the minimum should be 4 hours and the max should be 80 hours. You need to factor in the criticality, nature, and complexity of the work at hand when making a final determination as what will work best in your specific organization. Saving Changes...
As usual, the Tom, Michael, and Frank show are in near complete agreement, with slight nuances of difference of humble opinion.
Any such limitations on the duration of a scheduled task is wishful thinking. Work is defined by a handoff from predecessor to successor and by the unique resources associated with it, not the time to complete it. Let resources manage their own tasks, while using the PM process to manage the flow of handoffs.
I can see the interest in keeping a lid on scheduled durations -- at least the effect of Parkinson's Law will be limited. But such limitations can actually add risk if reources feel untoward pressure to complete work in that time.
My point of having an 80 hour limit on task duration is that you force each activity to be discreet. If a task is longer than 80 hours, the tasks often turns into a "level of effort" with little or no visibility. Show me a task greater than 80 hours and I'll show you how to break down the activity into discreet components for tracking purposes. Saving Changes...
9 times out of 10, I would bet that you wouldn't have to break the 80+ hour chunks into smaller pieces if the tasks were appropriately identified (using dependent handoffs and resources) in the first place.
The other 1 out of 10 might acutally be a long duration task. If the resource performing the work provides regular and frequent estimates to completion, then micromangement through tracking subtasks at the project level should be unnecessary.
Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
The nice thing about short duration tasks is that you can treat them as either complete or not complete. No need to track progress on them. As they begin to exceed 40 hours they need to be tracked as to their interim progress. Simpler is Better for me. One task-one person-one outcome. The more my project plans can be reduced to that level the easier to manage and control. Saving Changes...
Jim McVeyManaging Consultant| HeadstrongWoodbury, Mn, United States
Although I am a little late to this party, I would add two discordant notes to the above. The first problem with managing tasks below a 40 hour or 20 hour limit (my personal floor) is the shear task of managing the volume and dealing with the ramifications of a task that is not completed in time. The second is that planning at that level of detail more than a week or two in advance of the actual work - and hitting the target - is virtually impossible. So by managing to these smaller blocks you increase both the complexity of a plan and the likelihood that it will be wrong and much harder to fix. Stick to the rule of 40/20 unless forced to and make sure the extra PM work is baked in if it is required. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Interesting view, our experiences differ radically. I find the smaller the unit the more self managing the effort and the faster defects in the plan materialize and the quicker recalibrations can take place. I do however agree that precision too far out is folly. I usually create macro tasks and then about 30 days out explode them to smaller work units. So your point is well taken. Saving Changes...
James -- Might I suggest that the complexity of a project is not found in the number of tasks, but rather in the number of integration dependencies in the network. Might I also suggest that trying to manage individual tasks to be "completed in (on?) time" is a fool's errand. If the need to hit individual task due dates to keep the project under control is real in your environment, then I understand the fear of understanding tasks at an appropriate level of detail. I suggest that that need is and can not be real in the real world.
As far as what is involved in managing tasks under 20 or 40 hours is concerned, daily updates of estimated time to complete active tasks are all that is needed. That should be no more, and should probably be considerably less daily updates than the number of resources involved in the project.
1. Base the Work Breakdown Structure on the Product Breakdown Structure. 2. The level of granularity is based on two factors. A. How complex are the tasks. B. How experienced is the staff doing the task.
I follows rule number one because often I get task lists (WBS) that don't actually complete the product. It doesn't matter how detailed the wrong task list is.
Rule number two stems from some great direction on how detailed to make a spec that I read in "The Software Project Survival Guide." I find the same rules about how detailed to make the design documents wok great for making the task list. Saving Changes...
