The Schedule – Estimate Task Effort

"If you are distressed by anything external, the pain is not due to the thing itself but to your own estimate of it;  and this you have the power to revoke at any moment.”

                                                                                                                                - Marcus Aurelius

As we progress through this series on the well-formed schedule, we have taken the WBS and added the task dependency chain, leading to the next step:  estimate the effort for each task.  Whole books have been written just on estimating, and I’m not about to attempt to tackle the depth and breadth of the subject in this post.  Today I’ll focus on pointers and essentials.  I expect a number of future posts on estimating.

This post – in fact, this series of posts – is about developing the well-formed schedule.  It therefore describes best practices and assumes you are using best practices.  Specifically, that you are using task effort estimates.  I have dabbled around the topic of effort versus duration estimating in several previous posts, but have not focused on it specifically.  And it is too broad a topic for me to address it satisfactorily today.  For now, if you are using duration estimates instead, it severely limits the benefits of your scheduling tools.  I’ll come back to the topic of effort versus duration estimating in a future (series of) post(s).

Stating the blatantly obvious, since we’re developing task estimates from a WBS, we’re well beyond the stage of Rough Order of Magnitude (ROM) and top-down estimating.  However, we’re not yet at a defined estimate (say, -5% to +10% expected accuracy), but which is where we expect to be when we complete this series of scheduling steps.  We are at the first of an iterative series of steps of successive refinement.  In addition, as I’ve stated in the past, an estimate isn’t meaningful without the related risk factors.  These will be incorporated into the schedule at a later step in this schedule building process, but that means you should be noting the sources of risk as you develop these estimates.  You should also document all assumptions that factor into the development of the estimates.

Ideally the task owner should provide the task estimate, but assigning resources to tasks is another step that will come later.  So at this point you will have to do the best you can.  If you are a domain expert, you might come up with this first set of estimates (though there are many risks with this).  Alternately, another project team member who is a domain expert could develop the estimates.  Another approach is to use several expert team members and the Delphi estimating method, which I’ll discuss in a future post.  The Delphi Method is particularly effective for a variety of reasons (in fosters team camaraderie, consensus and consistency of expectations, it is a successive refinement method, it exposes “gotchas,” etc.).  (See also Wideband Delphi Process.)

Delphi may be too onerous, so a good alternative is the three-point estimate, which I’ll also discuss in a future post.  This has many (but not all) of the benefits of Delphi, and it flows right into the advanced “scientific” scheduling discussion that will follow this series on the well-formed schedule.

One thing about the estimates at this point is that they should be “resource independent,” or at least resource agnostic.  That is, for this exercise don’t assume a specific resource will be performing the task;  instead, assume a generic resource skill.  Later, the individual task estimates will be refined based on specific task assignments, the next step in the process and the subject of the next post.

In fact, there are a number of biases that should be avoided at this point.  For example, do not bias for resource availability or skill;  and do not bias for (your expectation of ) task duration.  Next steps will adjust for the former and the scheduling tool will adjust for the latter.

However, it is appropriate to bias for “productive” hours (again, assuming you are estimating effort hours).  Productive hours are those hours that the project team member is working on project tasks and contrasts with (non-productive hours) administrative activities, vacation, holiday, sick time and other absences, etc.  If the team resources have to account for all their time when recording their daily/ weekly activity, then this may already be appropriately factored.  If not, you may have to make adjustments within the tool.  For example, assume a task is estimated at 40 hours of effort.  One’s first expectation is that this is a one week (five day) activity.  However, a person working on this task will also check email, spend time talking on the phone to their insurance agent, landscape supplier, or home repair technician.  They may take a training class.  They make take an afternoon off to attend a school conference.

Over a long project, you may not know specifically when resources will take vacations, but you need to factor in that they will take some vacation sometime.  Such small amounts accumulate over the duration of the project.  Therefore, it is advisable to adjust the scheduling tool so that a workday is only, say, 6.5 hours, rather than the usual eight hours in order to accommodate these variances over the full project duration.

Next we’ll add resources to the project schedule.

This is a lot of material to pack into one post.  Where have I confused you, what do you agree with and disagree with?  What would you like me expand on in a future post?