The Schedule – Resource Leveling

“Happy people plan actions, they don’t plan results.”

                                                                                                                - Dennis Wholey

We are nearing the end of the series on scheduling basics.  We have taken the WBS, added the dependency chain, estimated the effort and assigned resources.  The next step to completing the well-formed schedule is to level the resource assignments.  This is done to:

• Prevent over allocation of a resource within the project
• Prevent over allocation of a resource across enterprise assignments
• Accommodate non-productive time and absences

First, let’s assume the project is in an organization following best practices.  In that case, all team members record all of their time each cycle to specific project tasks and to operations, administrative, absence, and other non-project activities.  Your project management software integrates with these time records (or time is entered directly into the software, such as Sharepoint wih MS Project EPM, Clarity or Primavera).  In this case, you already have all of the elements in place to just “push the button” on your project management software to resource level the schedule.  You will then want to review and fine tune the results.

On the other hand, if you do not have the luxury of these conditions, you have more work.  For example, you will have to tune and adjust using heuristics to get the right productivity factor so that you don’t over allocate resources within the project;  and it will be much harder to track other assignments and activities to prevent over-allocation across enterprise activities.

In either case, this step will be repeated regularly over the life of the project.  Rescheduling and replanning are regular activities in the Project Manager’s Cycle.

In my next post, we’ll conclude this series of posts on the basics of creating the well-formed schedule by discussing risk buffers.

If you are not in a “best practice” environment, what steps do you follow to produce a resource-leveled schedule?

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?

The Project Manager’s Cycle – Check Variances and Productivity

“Kevin, I see that for the Architectural Strategy Document, your task to track down all of the legacy systems we interface to is falling behind.  What’s going on?”

The next activity in The Project Manager’s Cycle takes as input the revised schedule from the replanning and rescheduling activity.  For this activity, the project manager compares the newly current project (cost and duration) schedule with the baseline to identify variances and develop appropriate response plans.

For example, the PM will review the current expected cost to complete each project deliverable with the baseline cost.  Not all shops track (dollar) costs, but resource hours can generally be used as a proxy for cost when effort-based scheduling is used.  (If you are not using effort-based scheduling, well, you are already behind the eight ball for best practices.)  For any deliverable where the current costs differ from plan by a designated percentage or dollar amount (say, 10%) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the cost/effort variances.

Likewise, for each project deliverable compare the completion dates with the baseline completion dates.  Again where the dates differ by a designated amount (say, two weeks) plus or minus, the PM should investigate and document the reason for the variance.  As appropriate, prepare an action plan for addressing the schedule variances.

As PM, you also want to review progress (effort and duration) at a more granular level to determine whether you are getting the performance and productivity from team members that you expect.  This is, of course, subjective.  Look at each active task and the team members’ recent reports for early warning signals that there is slippage or that you can act to prevent slippage.  Also look for patterns that should be factored into the remaining project schedule.  After all, you want to be already responding to variances long before the dashboard turns red.

Finally, having identified and explained the cost and schedule variances, consider whether project change management is appropriate.    That is, are the changes caused by the team or because the plan was faulty (absorb the variance) or because of scope, environment, risk, or client events (change is appropriate).

How high do you allow the variances to get before you step in?  How do you typically raise the need to discuss a variance with a team member?  When do you escalate?