Project Management

Project management: Use an estimating threshold for schedule activities

To use the Work Breakdown Structure (WBS) technique, you have to determine an estimating threshold.

When you create a schedule you generally don't know enough to enter all of the detailed activities the first time through. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

An appropriate question to ask is how small the activities should be before they don't need to be broken down further. This is referred to as your "estimating threshold." You can break work down into activities smaller than the estimating threshold, but you would normally leave no work at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5,000 effort hours or more), any work that is greater than 80 hours of effort should be broken down into smaller pieces. Medium-sized projects (say 1,000 effort hours) should have activities no larger than 40 hours. If the project is small (say 200 hours), you should break down the activities into work no greater than 20 hours. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows you to manage the work better. For instance, if your project is 250 hours and you have activities that are 80 hours each, you won't have enough time to recover if one of the activities is late. However, if the largest activity is 20 hours, you can find out much more quickly if work is not being done on time. 

Of course, it's possible that you can't break down some activities less than the threshold that because there may be too much that is unknown about the work itself. In this case, the distant future work can be left at a level higher than the threshold. However, if you leave future work at a high level while it's in the distant future, you should still break the work into smaller pieces at least two to three months before you need to start executing the work.

In addition to allowing you to manage the work more effectively, another reason to break down activities into smaller pieces is to make sure you understand what the work means. When you assign a team member an activity from the schedule, he may not understand what the work is and he may ask you for an explanation. If you don't know what the work means either, you'll be in trouble. For instance, if an activity that's estimated at 80 hours has never been done before, it may still need to be broken down into smaller activities to ensure that the team member that is assigned the work knows exactly what is expected.

These two factors -- the ability to manage the work effectively and to understand the work required -- should drive your decision on how small to make your activities. 

12 comments
stuart
stuart

After reading this report I did sit back and wonder what I had just read. The information is what I would consider to be factualy correct however, I am worried that articles are being produced that state the 'obvious'. These 'Best practices' are taught throughout the world of project management. Are we just copying lecture and book material now for the sake of content? I don't mean to offend anyone with these comments as at the end of the day it is only my view and I could well be out of order. Thanks

mark2631
mark2631

Not only is this article merely a synopsis of classroom lecture, the method described is flawed. The WBS methodology described is a PMI concession to Microsoft that uses the "successive decomposition" of tasks to be the WBS. In a purist sense (and the original PMI standard and still the "best practice") the WBS is a "deliverables-oriented" tree structure using the described method to decompose deliverables into smaller parts until the work required to deliver the item can be accurately estimated (to deal with another part of this thread). The method described invariably causes items to be missed, as team members concentrate on the "how" instead of the "what" is to be delivered.

daniellgtr
daniellgtr

While I agree that most, if not all, of the information posted in white papers and articles does duplicate the best practices that are provided by courses, international standards, and the PMI. I think that some of the value of these articles is that they are freely available, especially if someone is interested in a particular aspect of project management and doesn't want or need to pay the money for a course or to buy a standard.

Wayne M.
Wayne M.

Stuart is correct. Anyone who cares to can review Mr. Mochal's history of articles and see that they are primarily basic introductions to project management terminology. This level may be the intent of the article series, but I would be concerned about anyone doing project management work who found this description of WBS insightful. P.S. Since when does 5,000 hours constitute a large parject? By my rule of thumb calculation this is less than 3 staff over a year.

thomas.peterson
thomas.peterson

I work with a lot of PMs that look to me to help them determine 'how long will it take to do a func vs tech spec'... I have yet to find an effective way of saying if project-size = Medium, scope = X & Risk = Y, and Quality = 3 then I should spend 60hrs on the FS, 285hrs on the TS, 800hrs on the test plan & execution, with 400hrs of build etc... I can definitely appreciate breaking down the project artifacts and deliverables into bite-sized tasks such as Draft=10hrs, Review=2hrs, Approval=.5hrs, Rework=2hrs...etc However, does anyone have a non-proprietary .xls or algorithm for doing a High-Level of Effort estimation they would be willing to share? Thanks in advance,

raintree
raintree

Since I work in an office where I am the only "real" project manager and I get a lot of flak about "taking too much time" planning, I really like to have reminders of the basics. Without them it would be much too easy to slide back into the old sloppy flying-by-the-seat-of-the-pants approach.

mike.normand
mike.normand

As a newbie to the Project Management world I found this article, written by a well respected PM working in the real world, re-enforced what I have been learning. For the seasoned PMs I can understand their reasoning but for rookie's like me the article was relative.

geoff.schmidt
geoff.schmidt

I, too, lifted my eyebrows in surprise when 5000 hours was deemed a large project. This a small to medium project where I work. :) The basic rules are valid, imo. However, a bottom threshold should also applied, ie, don't estimate tasks less than 1/2 or 1 day, and roll up lots of smaller tasks into a larger one and estimate that. People can get caught breaking down tasks too far (telephone calls, meetings, meeting prep, minutes, etc...). Consideration is also needed as to the measurement used - days or hours. Each has their pros and cons. Days can be too coarse - smallest task is always at least 1/2 day, which can blow out your estimates. However, hours can be too fine, and unexpected meetings and other outages, etc, can also blow out the work.

carynt
carynt

I too found the information a good reminder as I generally have more than a dozen projects going at once that I can easily forget this as I try to do it "all". It was a quick read and well worth my 2 minutes.

tseals8
tseals8

The article goes without mentioning Pert Estimates. I think it is related and should have been included. PERT = Min Time+Max Time+4(Best Estimate)/ 6

Wayne M.
Wayne M.

Aside from converting things to hours to make the reports people happy, I rarely estimate at anything smaller than the deliverable level with man-weeks as a unit. Given my lack of brainpower, I really can't deal with 100 - 500 line WBS charts that result from lower level estimations.

Editor's Picks