This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.” I first gave this talk at a Puget Sound PMI chapter meeting. I later gave an updated version of the talk to my local chapter of the MPUG Project User Group. As you might expect, at the PMI meeting the discussion tended more towards the broader project management issues, while at the MPUG meeting more towards specific features in Project. In fact at the MPUG meeting I had my computer projecting and we played around with Project features that related to some of the issues I brought up.
Top Ten List
In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.
Problem #5: Expect that automatic resource leveling should be able to alter reality
When I talk about resource leveling, I really have to clarify that this can mean one of two things. Manual resource leveling includes a broad range of actions I can take where the end result is that for some given time period, a resource ends up with a different amount of work assigned than they previously had. I literally level (or make even) the resource's workload. Usually we’re most concerned about addressing overallocation problems—a resource has been assigned, say, 60 hours of work for the week but their normal working time allows for at most 40 hours. But I might also be concerned about addressing underallocation problems.
The other meaning of resource leveling is the automatic feature (Tools menu, Level Resource command). This is the amazing Project feature that does some impressive math tricks to smooth out resource allocation problems, but produces a result that you often do not want—an extended finish date. Don’t blame Project though, it can’t alter reality. You know the expression, you can't have your cake and eat it too?
Walk a mile in my shoes
Let’s look at an example of a resource overallocation and how I can go about resolving it. Here’s the initial state of my project plan.
TIP Click the screenshot image to see a larger view.
At first glance this appears to be a nice, concise schedule with simple task relationships. Put yourself in the shoes of the Screenwriter or Director however and look at the tasks to which you are assigned. One quick way to do this is to filter the Gantt chart (Project menu, Filtered For submenu, AutoFilter command) and then filter the Resource Name column for each resource. Here’s the Screenwriter’s tasks:
And the Director’s tasks:
These both appear to be resource overallocations: each resource has at least one case of overlapping assignments that result in them being assigned more work in a given time period than they would normally be able to complete. In other words, for some amount of time their Max. Units values have been exceeded.
Let's all stay level-headed here
Now I’ll switch to a different view to see how bad the overallocations are. There are a few different ways I can get this information, but my favorite is the Resource Usage view (View menu). This is the evil (or good) twin of the Task Usage view. In this case, assignments are grouped per resource.
I’ve adjusted the timescale of the view such that it’s easy to see week-by-week where the overallocations occur. For the Screenwriter, it’s the week of March 28 and for the Director the week of April 25.
In this view the names of the Overallocated resources are formatted in dramatic red, and I get a little indicator as well:
One reason I like the Resource Usage view is that I can directly edit the assigned hours per time period right here. For the Screenwriter, for example, I can see that she is assigned full-time (40 hours per week) to two tasks at the same time: Develop script and Develop production boards. Assuming the Screenwriter really has only 40 hours of total capacity to work the week of March 28, I can decide how I want that capacity split between the two tasks. I’ll go for a simple 50/50 division, and enter 20 hours per assignment on these two tasks:
And just like that, I’ve manually resolved this overallocation.
Moving on to the Director, I see that he too has multiple overlapping assignments the week of April 25: Pick locations and Rehearse. I mentioned the automatic leveling feature above; let’s give it a try.
Because I’m interested in see the overall duration of the project plan, I’m going to switch to a split view: Gantt Chart on top and the Resource Usage view below. When used in a split view this way, the Resource Usage view displays the assignment details for the resource or resources assigned to whatever task I have selected in the Gantt Chart view. In this case I’ll select task 4:
Now I’m ready to fire up the automatic leveling feature via the Tools menu, Level Resource command.
It’s a complex dialog box and Tim and I walked through its options exhaustively in the Step by Step books. It also has pretty good documentation via the Help button.
One thing I need to clarify is that in the dialog box the options under Leveling Calculations are a bit confusing. “Automatic” means to automatically level resources continuously as any details in the schedule may change. I can’t think of any cases where I’d want to do this. “Manual” means to automatically level resources when I click OK in this dialog box. It’s not the same meaning as manually leveling resources by, for example, adjusting assignment details like I did above for the Screenwriter.
The most critical setting in this dialog box, and the one that is easy to miss, is the “Level only within available slack” check box. If checked, Project will make whatever leveling adjustments it can without extending the project finish date. If unchecked (the default), however, Project will extend the finish date as needed. Let’s see what result we get with the default settings.
But wait! There’s another interface oddity about this dialog box—clicking OK simply saves your automatic leveling settings but does not execute on them! I need to click the “Level Now” button to get this beast rolling. Here’s the result:
Project did indeed resolve the Director’s overallocation problem. He now has just 40 hours scheduled for the week of April 25. Project accomplished this by just delaying the start of task 5 by a week, which correspondingly pushed out the finish date of the project. Since I can’t live with this consequence, I undo the result by returning to the Resource Leveling dialog box and clicking the Clear Leveling button.
Next I’ll level resources but I’ll click the “Level only within available slack” check box because I really don’t want the plan’s duration to increase. Here are the result:
Turns out there is no way to solve this overallocation without extending the duration or (as we did for the Screenwriter earlier) reduce the amount of work.
Now if you’ll excuse me, I feel like having some cake. See you next week.
Hands-on with Project Step by Step
To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.
Editing assignment details in a usage view
- Project 2007 Step by Step: "Manually Resolving Resource Overallocations," pg. 199.
- Project 2003 Step by Step: "Manually Resolving Resource Overallocations," pg. 180.
Automatic resource leveling
- Project 2007 Step by Step: "Leveling Overallocated Resources," pg. 203.
- Project 2003 Step by Step: "Leveling Overallocated Resources," pg. 184.
- Project 2007 Step by Step: "Examining Resource Allocations Over Time," pg. 191.
- Project 2003 Step by Step: "Examining Resource Allocations Over Time," pg. 173.
Comments