Resource Leveling: Problem Indicators

Who doesn’t like a good mystery movie? They’re chockful of timelines, inter-related events and lots of clues that, when understood, help the viewer arrive at a solution. These same attributes can also describe an uncooperative project schedule. But while a good mystery is entertaining and goes great with popcorn, a project schedule that won’t schedule or level correctly can be downright frustrating. Luckily, Microsoft Project provides clues to help identify and correct leveling issues, if you know what to look for.

Project provides the project manager with clues in the form of visual indicators. The indicators are used to convey information and identify problems. Both types do what they sound like. Informational indicators provide information. Problem indicators tell the project manager that there is, or might be, a problem here. In this article I discuss the different types of indicators and what they’re telling us and in some scenarios show how a sample problem could be corrected.

Informational Indicators

Informational indicators are icons displayed in the Indicator column of a task or resource view. They are informational only and as such don’t necessarily mandate any actions by the project manager. However, there are two types with subtle differences. The first type is purely informational. For example:


The task is complete

The task is recurring

The resource is a local resource

The second type tells the project manager, “There’s something atypical about this task.” For example:

The task has an inflexible constraint
The task has an external dependency
The task has a custom workload pattern

While atypical indicators can be purely informational, they also tell the project manager to “be aware” because they can also be clues pointing to the root cause of a scheduling or leveling problem. For instance, remaining work stuck in the past may be the result of an inflexible constraint, or a gap in resource usage may be the result of a task calendar specifying that work can only occur on Tuesdays.


Want more? Watch Daryl Deffler’s two-part webinar series on resource leveling, now available, on demand.

Read Daryl’s articles in this resource leveling series here:
“Scheduling vs. Leveling”
“Problem Indicators”
“Leveling Mechanics”
“Leveling Hierarchy, Part 1”
“Leveling Hierarchy, Part 2”
“Resolution Options”
“Understanding Split Task Options”
“Leveling Fields”
“Limitations”
“Preparing to Level”
“Resource Leveling: It’s Time to Level Your Schedule”
“Resource Leveling: The Leveling Cycle”
“Resource Leveling: Recommendations”

Also, download a resource leveling “cheat sheet” in PDF format!


Problem Indicators

Project uses several types of visual indicators to notify the project manager, “There’s something wrong here and you should probably fix it.” These are problem indicators, which can be displayed in two ways: 1) as icons in the Indicator column; or 2) as a red bit of text, a number or a graphic. Problem indicators come in two flavors as well: those signifying leveling issues and those representing overallocation.

Leveling Issue

These indicators are icons displayed in the Indicator column. They highlight non-resource-related problems that couldn’t be resolved by the leveling engine. For example, a constraint violation is designated with this icon:

In the sample below, task 7 contains a “Finish No Later” than constraint of June 29, but the task is finishing in August.

There’s also the non-intersecting work calendars indicator:

This scenario is illustrated by task 70 below. While the task uses a Monday through Friday workday calendar, the assigned resource can only work on Saturdays:

Overallocation

These indicators highlight resource-related schedule problems. While these indicators include icons displayed in the Indicator column, they also include red text, numbers and graphics that can appear just about anywhere.

Resource overallocations identified within the Indicator column are illustrated below.

 

The red “burning man” indicators appears in a task view; the yellow diamond appears in the resource view.

This sample illustrates the overallocation of a resource in the task view (indicating that at least one resource assigned to the task is overallocated):

This shows an overallocation in the resource view (including that the resource has at least one task assignment on which he or she has been overallocated):

Note: The resource name also appears in red to indicate an overallocation.

As I noted, Project also indicates overallocations by displaying red text. In the sample below, it’s obvious Joe is overallocated because the Name and Work columns are red. Additionally, looking at the timescale data, it’s clear that Joe is overallocated Monday through Thursday because the summary row totals by period are red. But digging a bit deeper, you can also see that Joe is overallocated on “Test Task” because those task-specific numbers are also displayed in red. But why are only the summary and Test Task numbers displayed in red? I’ll discuss that in a moment.

Finally, overallocations can also be seen in graphics. Here’s Joe’s overallocation in a resource graph. Joe’s name appears in red and his overallocations appear as the red bars in the stacked graph:

Here it is in Team Planner, where his name is shown in red and the days on which Joe is overallocated are bracketed in red:

Overallocation Types

As I mentioned earlier, there are two types of overallocations: by time and by task. As a project manager, you need to be able to distinguish them and understand how to correct each. Let’s re-examine the earlier example.

You can identify time overallocations by looking for red numbers within the summary row of a Resource Usage view. The sample above illustrates this. The summary allocation for Joe is 56.67h on Monday, 64.67h on Tuesday and so on.

Time overallocations occur when the sum of multiple tasks in the same period exceeds the resource’s maximum availability. The sample shows that individually, Tasks 10 through 15 are fine. But when summing these tasks along with Test Task, the total exceeds resource availability and the resource ends up overallocated.

There’s a good chance that resource leveling will fix these issues. However, it’s always possible for a talented project manager to induce these types of problems by using techniques like hard constraints or manual tasks that resource leveling can’t fix.

You can identify task-specific overallocations by looking for red numbers appearing on a specific task within a Resource Usage view. This is illustrated on Test Task in the sample above.

Task-specific overallocations are caused by the combination of task configuration and resource assignment. Looking at the Test Task sample, Joe is available to work eight hours per day. But in this sample, Test Task was created as a three-day fixed-duration task with 50 hours of work. As a result, Joe ends up allocated 16.67 hours per day which obviously exceeds his daily eight-hour capacity.

The second example is a bit more perplexing. There’s only one task assigned and the total work is one hour. So why is Project flagging this as an overallocation?

In this sample, the resource max units is 85 percent, meaning the maximum the resource can be assigned to any unit of time is 85 percent. For example, 85 percent of an eight-hour day would be 6.8 hours. And 85 percent of a 60-minute hour would be 51 minutes. In this case, the resource was assigned at 100 percent (60 minutes) to a one-hour fixed-duration meeting task. Because the 60-minute resource assignment within this one-hour period exceeds the 51 minutes the resource is available in that period, that specific period (not the task) is flagged as an overallocation.

Since resource leveling won’t fix either of these examples, you as the project manager would be required to adjust either the task or assigned resource to correct the overallocation.

Project’s Clues

Project provides lots of clues in the form of visual indicators to tell the project manager that something’s wrong or may be a concern. These indicators may point to specific issues or they may point to something that could be the indirect cause of an issue. Understanding how to interpret these clues can help you resolve schedule and leveling issues and ultimately build better project schedules.

However, I offer this caution: Problem indicators don’t identify all scheduling and leveling issues. But we’ll leave that discussion for another article.

Additional information about the Indicator icons can be found at this Microsoft support link.

Next time, we begin to examine leveling components, starting with leveling mechanics.

Next Webinar

Survey: Reporting Bad News about Projects

Written by Daryl Deffler
Daryl Deffler is currently employed by a large insurance company where he provides project management, project scheduling tool, process, and standards consulting for an enterprise project management office comprised of about 200 project managers. He has over 25 years in the IT project management field with experience managing small projects to large programs. During this time he has also developed and taught classes in both project management and scheduling tools such as Microsoft Project 2013, Primavera and ABT Workbench. He has been employed in the IT industry since 1979 in additional roles, including software development, technical support and management across mainframe, midrange and PC platforms.
Share This Post
Have your say!
00

Leave a Reply