Assignment Units in Project 2010

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:

· Overallocation 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 duration) 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.

Comments

• Anonymous
  April 29, 2010
  Brian, your explanation is very thorough, however the Microsoft made a wrong design choice in my mind. Microsoft decided that the Asssignment Units field should now always reflect what you manually entered. To the user this will appear as if the formula does not work any longer because it does not recalculate the Units any longer as it did in EVERY previous release. Thousands of people have been using this fomula and manipulating their schedules with it. Knowing and using the formula gave a sense of mastering the tool. What should Microsoft have done to solve the issue with the actual hours driving the Assignment Units? Microsoft should have calculated the Assignment Units based on the Remaining Duration part of the task instead of on the entire Duration. This would have taken care of the problem without causing such an upheaval among people who monitor and rely on the formula to manipulate their schedule. I hope Microsoft will still reconsider its poor design choice.

• Anonymous
  May 03, 2010
  I think this is a good change... but not quite there yet. For example, why do the "Work" and "Actual" values both change from 8 to 10 hours on Wednesday ? Surely "Work" should reflect what was planned i.e. 8 hours, and "Actual" should reflect what was really spent i.e. 10 hours. Maybe you can add to this explanation (which is very good, by the way) why this is ?

• Anonymous
  May 03, 2010
  Eric, your idea is clear, but in my opinion the changes were absolutely right. One value should not be both given and derived. Otherwise it's hard to understand if it is in one state or in another.

• Anonymous
  May 04, 2010
  Work = Actual Work + Remaining Work which means if you increase Actual Work, Work will increase. That way you can always look at the Work field to see how much total work is in your project (planned and actual). If you want to preserve the originally estimated values, you need to save a baseline. Thanks.

• Anonymous
  May 04, 2010
  It is wonderful

• Anonymous
  May 07, 2010
  The peak value is good enough to find any cases of a daily overallocation. Maybe track overtime. But it doesn't actually show if the task as a whole is overallocated or not. Imagine a task with 8h work on Monday, 10h on Tuesday and 4h on Wednesday. The peak value would be 125%, but the average allocation 91%. This information would be interesting to determine if the task was doable at all in the predicted amount of time. One could also know if there is potential space to deal with the overallocation without prolonging the task...

• Anonymous
  May 07, 2010
  It is much clearer with the added column "Peak". I just wonder in the Fixed Duration scenario, what if on the third day, Steven worked only 6 hours, does it mean in the Peak column, it will show 75%?

• Anonymous
  May 07, 2010
  One thing for sure, we'll all still be trying to master the nuances of project for a long time to come.  Good consulting revenue though...

• Anonymous
  May 11, 2010
  LJW, the Peak field has actually been around for a while, you could add it to the resource usage view, but it was just a dupe of the Assignment Units field. Also, the Peak field always shows the maximum assignment value for the whole assignment. In the case you mentioned if Steven only worked 6 hours on the last day Peak would be 100% as determined by the first two days of 100% allocation (8 hours in this case).

• Anonymous
  May 11, 2010
  This question is tangentially related to this article. Has Project/Project Server 2010, by chance, added the concept of Assignment Units at the project level? For example, we often have the scenario where a resource can spend 50% of their time, but no more on a project, so we want to see assignments balanced at the project level based on that allocation. This can be done by customizing each task assignment, but we hoped for something more automatic. Thank in advance for any information.

• Anonymous
  August 19, 2010
  This seems to mostly make sense, however it might have been nice then if Microsoft had carried the Peak field into the Task Details form, as well as others since from these views only display the Assignment Units.  Or allowed the user to insert other fields into Task Details form as an example to at least customize them as necessary to see the Peak field.   Since this information is not available in the Task Details view, it just looks like the product is broken.  Fixed duration 5 day task, 20 hours on each resouce (2 total), shows 100% Assignment units, just doesn't seem very intuitive.

• Anonymous
  December 29, 2010
  I accidentaly deleted the comment asking if this means Work = Duration * Units no longer applies. Yes, that equation still applies, nothing has changed there. What we have changed is when units show up next to the resource's name in the Gantt Chart and what units value (assignment units or peak) is used in this calculation when the duration of a task is changed.

• Anonymous
  September 16, 2011
  This is a very thorough explanation of the change. I do have one question. You say it is possible to manually set Allocation Units to display in the Gantt chart. When I attempt to do this using Bar Styles, Text tab, 'Allocation Units' is not listed in the dropdown menu. Does Project know it by another name? If so, what? Technically, that's two questions... Thanks!

• Anonymous
  October 04, 2011
  This sentence "You can still set it manually and it will show up in the Gantt, is actually saying something else". You can't control when/how assignment units shows up next to the Gantt bars. It is saying that if you manually set assignment units to a non-100% value, it will show next to the resource's name on the Gantt bar.

• Anonymous
  November 21, 2011
  However when the Task Type is Fixed Work, when the duration is altered the Units has to change correspondingly.  With the same resources assigned the duration increase means, for a Fixed Work, the number of hours spent per day is reduced.  This is important to manage multiple projects with same resources.

• Anonymous
  March 28, 2012
  The comment has been removed