This week I continue the “highlights of highlights” series: I include some excerpts from the Project 2010 Step by Step chapters and elaborate on them. This week: Chapter 10, "Fine-Tuning the Project Plan."
The relationship between a resource’s capacity and his or her task assignments is called allocation. Each work resource is in one of three states of allocation:
- Underallocated The resource’s assignments do not fill the resource’s maximum Capacity to do work. For example, a full-time resource who has only 25 hours of work assigned in a 40-hour workweek is underallocated.
- Fully allocated The resource’s assignments fill the resource’s maximum capacity. For example, a full-time resource who has 40 hours of work assigned in a 40-hour workweek is fully allocated.
- Overallocated The resource’s assignments exceed the resource’s maximum Capacity for any period of time. For example, a full-time resource (pp. 211-212)
Optimizing resource capacity is a real strength of Project, and especially important in projects that involve expensive or hard-to-find knowledge workers. In this section of the chapter we dive into the Resource usage view and get a very detailed look at who's got what allocations over time.
The red formatting means that these resources are overallocated: at one or more points in the schedule, their assigned tasks exceed their capacity to work. (pg. 215)
Project formats the names of overallocated resources in red. In many cases though, this red formatting results in a "boy who cried wolf" situation. As we describe in the chapter, you have control over the granularity of time Project should use when determining a resource's state of allocation. For myself and most knowledge workers I know, I prefer to manage my allocation at the weekly level. In other words, most of the time I regard the workweek as my essential unit of working time. I tend to organize my specific tasks per week, and manage my workload (i.e. my allocation) during the week. I'm not particularly concerned if I have, say, 10 hours of work scheduled on one day. I can manage that. Project however, using its default setting of flagging overallocation on a day-by-day basis, would flag this as an overallocation and format my name in alarmingly vibrant red.
In this section, you will manually edit an assignment to resolve a resource overallocation. In the next section, you will automatically resolve resource overallocations. (pg. 217)
This excerpt is from the section titled "Resolving Resource Overallocations Manually" and brings up a peculiar semantic point of confusion. In Project, there are broadly speaking two ways to resource resource overallocations:
- Manually, by editing specific assignment details (as covered in this section)
- Automatically, by using the Level feature.
Here's the confusing bit. The Level feature has two modes: Manual and Automatic. We highly advise against using automatic leveling (which really should instead be called "continuous"), so we have to wordsmith our way around the confusing notion of "automatically level with manual leveling."
Resource leveling is a powerful tool, but it accomplishes only a few basic things: it delays tasks, splits tasks, and delays resource assignments. It does this following a fairly complex set of rules and options that you specify in the Resource Leveling dialog box. (pg. 222)
This is in the context of the automatic resource leveling feature, not manually editing resource assignments. For simplicity, I'm going to call the feature "automatic resource leveling." Automatic resource leveling is probably one of the most powerful features in Project from a pure number-crunching sense, but ultimately may also be disappointing for many users. That's because (as we illustrate in the section) Project can only work within the parameters you set for it. In many consultations I've seen Project plans with severe resource overallocations, and the project manager is unable or unwilling to extend the project end date, cut scope of work, or add resources. Consequently, the automatic resource leveling feature can't fully resolve the overallocations. This is a specific case of the general problem of wanting something for nothing.
In the language of project management, a project’s finish date is determined by its critical path. The critical path is the series of tasks that will push out the project’s end date if the tasks are delayed. For this reason, when evaluating the duration of a project, you should focus mainly on the tasks on the critical path, called critical tasks. Remember that the word critical has nothing to do with how important these tasks are to the overall project. The word refers only to how their scheduling will affect the project’s finish date. (pg. 228)
"Critical path" is one of those phrases I often hear used with the wrong intent. When I hear the phrase used, it's often in the context of "this work is really core to the nature of the project" and not "this work drives the finish date of the project."
Previous posts in the "Detailed Commentary" series:
Part 1, Simple Scheduling
- Introduction of Project 2010 Step by Step
- Chapter 1, "A Guided Tour of Project"
- Chapter 2, "Creating a Task List"
- Chapter 3, "Setting Up Resources"
- Chapter 4, "Assigning Resources to Tasks"
- Chapter 5, "Formatting and Sharing Your Plan"
- Chapter 6, "Tracking Progress on Tasks"
Part 2, Advanced Scheduling
- Chapter 7, "Fine-Tuning Task Details"
- Chapter 8, "Fine-Tuning Resource Details"
- Chapter 9, "Fine-Tuning Assignment Details"