If you are an experienced project manager then it’s likely that you are familiar with the Assignment Units field. For those who aren’t, Assignment Units determines the rate at which a resource is assigned to work on a task. This field is set to 100% or the Resource’s Max Units (whichever is the lesser of the two) by default, although it can be less or more depending on the needs of the project manager. In Project 2007, and previous versions, when this value differs from 100% we show it next to the resource name in the Gantt chart. For Project 2010 we’ve made some changes to the way that the Assignment Units field is calculated. Primarily, these changes were made in response to customer feedback about the way calculations were impacted when resources entered overtime work. For this release we’ve clarified the definition of the Peak field and the Assignment Units field which previously had some functional overlap but now fill more defined, separate, roles. As a result of these changes the Assignment Units field is no longer automatically modified to be greater or less than default value of 100%; as a consequence the field does not show up in the Gantt chart as often as it used to. This has led to some confusion which I’m hoping to clear up with this post.
For an example of this, see the two screen shots below in which all the three day, fixed duration tasks were increased to 30 hours of work (up from the initial 24 hours of work) after the resource had been assigned to the task:
Project 2007 SP2:
Project 2010 (Auto Scheduled task and Manually Scheduled task):
In Project 2010 we still show Assignment Units in the Gantt when the value is directly altered from 100%, but we have changed the product behavior so that changing scalar work after making an assignment on a task will no longer automatically alter the Assignment Units field as it did in previous versions.
To understand the new behavior let’s have a short look at the intent and purpose of Assignment Units. When a resource is initially assigned to a task in Project there are three important values that characterize the assignment: duration, assignment units, and total work. The equation that governs the relationship between these three values is one of the core project scheduling functions, sometimes called the “iron equation of scheduling.” It’s defined:
In this way a resource with the standard 8 hour/day calendar assigned at 100% to a 3-day task would be calculated:
Thus, the assignment would have 24 hours of total work.
But as it turns out, in previous versions of Project we were using the Assignment Units field to track two slightly different aspects of the resource assignments on each task:
· Keep track of the workload initially assigned to the resource as detailed above.
· Show the maximum workload experienced by or assigned to the resource.
Because the field was being asked to do two different things users could experience inconsistent behavior around the extending of task duration in versions of the product prior to 2010. To help resolve this inconsistency we’ve leveraged the Peak field which already handles the second function leaving the Assignment Units field free to track the workload as initially assigned. Here’s an illustrative example:
Let’s say that we have a three day, fixed duration task and let’s assign this task to Steven who’s working with the standard 8 hour/day calendar. When we make the assignment we see that Steven has 24 hours of total work for the assignment. This is how it will appear in Project 2007:
And now in Project 2010:
So far, things are about the same.
Now let’s increase the scalar work on the task to 30 hours, that is, change the value for Work in the table on the left from 24 to 30 hours. In both versions we see that the work is distributed evenly (according to the default flat contour) across the three day assignment. Remember, the task is fixed duration not fixed units, so the work assigned will change to accommodate the new increased workload. In Project 2007 the value for Assignment Units increases to 125% to accommodate the change in total work on the assignment:
In this example, any increase in the duration of the task would result in work being defined according to the Assignment Units value consistent with 10 hours/day. This is not consistent with the desired behavior for Assignment Units which is to maintain the value at which the resource was initially assigned to the task. According to our iron equation, and customer feedback, the subsequent edit of scalar work should not have caused the Assignment Units value to be altered.
In Project 2010 we see that the Assignment Units field has remained at 100% which was the workload initially assigned to the resource while the Peak field has changed to reflect the maximum workload on the resource of 10 hours/day:
There are two assertions that we have made in the conceptual framework around the scheduling engine that are now better served by the new differentiation between the Peak field and the Assignment Units field:
· Overalloc
ation should only be indicated when the resource is directly assigned more work than a can be completed at the Max Units allocation. Many users used the Assignment Units field as displayed in the Gantt chart as an indicator of overallocation. This was not always accurate.
· Increases in task duration should maintain the initial assignment allocation.
Here are a couple examples that demonstrate these points:
Overallocation
Take the previous example’s three day task. Let’s say that Steven worked on the task and entered actuals as shown below. For the first two days he worked 8 hours per day, but on the last day he worked 10 hours to ensure that all work on the task was completed. Here in Project 2007:
Note two things here. First, the value for Assignment Units is calculated based on the maximum effort expended by the resource on the task, which in this case is 10 hours on the last day of the assignment. Because of the increase in the value for Assignment Units the relationship between assigned work, duration, and assignment units is not valid for the first two days of the assignment. Additionally, this Assignment Units value will now appear in the Gantt chart seeming to indicate an overallocation even though the Project Manager did not assign Steven to more than 8 hours/day initially. This violates our first scheduling assertion.
Now let’s examine how Project 2010 handles the scenario:
Here we see the Peak field is still 125% which is consistent with the additional actual work on the last day of the assignment. However, the Assignment Units field remains 100% and will not show an apparent overallocation for the resource consistent with the initial allocation. The scheduling assertion that overallocation only be shown when created by the Project Manager is maintained.
Additionally in Project 2010 we’ve added new UI elements that help users more easily identify when a task contains a resource overallocation. The primary element to demonstrate this condition is the red “overallocation indicator” shown next to the task name in the grid:
We’ve also provided the Task Inspector which provides more information regarding issues with the assignment, and guides the user to possible solutions:
Increased Duration
Continuing with the previous example Steven enters 10 hours for the last day of the assignment as previously described and then the Task Duration is extended by two days, the new work would be determined based on the Assignment Units. While this is the correct conceptual behavior we see the following in versions leading up to and including Project 2007:
The two new days are assigned at 10 hours per day. It’s unlikely that the Project Manager expects Steven to work at the same rate as he did on Wednesday, so extending the assignment at the rate of 10 hours/day is not expected given the Project Manager’s initial assignment of 8 hours per day. Additionally, the new work has been assigned in a way that will make it impossible for the built-in tools, like resource leveling, to resolve the overallocation and difficult for new/novice users to correct the issue. Simply changing the Assignment Units field back to 100% will not fix the problem; it will just scale the work contour.
In Project 2010, we see the following behavior:
This is more in line with what the Project Manager might expect and consistent with our conceptual framework. New work should be assigned at the original workload, and the resource should not appear over allocated. In this case we see how we are not more consistently following the Iron Equation when it comes to assigning new work to the resource. Here’s the breakdown:
Where the Peak field captures the max (or “Peak”) assignment value of 10 hr/day for the Wednesday of the assignment.
Common Questions
A couple common questions have cropped up around our new behavior in this area, and I’ll try to address them here.
“Allocation units no longer display in the Gantt!”
Actually it does. You can still set it manually and it will show up in the Gantt. As previously mentioned some users were relying on the appearance of the Assignment Units field in the Gantt to indicate overallocation on a task but this was not the intended use of the Allocation Units field and was potentially inaccurate way to determine overallocation. Instead we’ve provided the overallocation indicator and the task inspector for this purpose.
“Why not show the peak field in the Gantt instead of assignment units?”
The display of the Allocation Units in the Gantt chart was meant to inform the user when they have a resource assigned to a task at a value other than 100%. If we show the Peak field in the Gantt there is potential that it would show up even when the user had initially assigned the resource at 100%. One example would be when accepting actual work updates from my tasks.
“How is VBA based on the old behavior impacted?”
Any script that relied on the Assignment Units field showing the maximum value for the assignment on a task should be altered to reference the Peak field for this information instead. Also, note that edits to the duration or timephased work or actual work for the assignment will no longer impact the Assignment Units field. If you want that field to change when any of these values are altered you must now explicitly set the Assignment Units field directly but also note that changes to the Assignment Units field directly will impact the assignment work (fixed d
uration) or task duration (fixed units) the same way they did in Project 2007.
“What about fixed units tasks?”
The only difference between the fixed duration tasks as described in this post and tasks that are defined as fixed units is that when the scalar work on a fixed units task is changed the duration of the task will change to accommodate the additional work. Here’s a demonstration of the “increase scalar work on the task to 30 hours” example from above but using fixed units tasks instead of fixed duration. First Project 2007:
And now Project 2010:
Because we are working with fixed units tasks, edits to the scalar value for work will not impact either the Assignment Units field or the Peak field. However, if timephased work entry will behave consistent with the behavior observed in the examples for fixed duration tasks.
Hopefully this clears up some of the questions around the changes made to the Assignment Units behavior in Project 2010. We feel that the end result is more in line with what users expect from the product, and will resolve some longstanding complaints around overallocation and task extension.
Leave a comment!
You must be logged in to post a comment.