jxProject Icon jxProject.com

jxProject Advertisement
. Home Products Advertising News About Contact Legal

Purchase / Buy


Future Plans



jxProject 0

JxProject – Resource Leveling

User Documentation

June 19, 2012


Resource leveling involves accounting for the availability of resources when scheduling tasks and preventing resources from being over allocated.  A resource is over allocated when scheduled to perform more work than is possible within the resource's schedule.  Example: If a person is scheduled to work 8 hours on Monday and is then scheduled to work full time on four tasks on Monday, then this resource would need to put in 32 hours of work to stay on plan.  It is not possible to work 32 hours per day! In order to build a realistic project plan, resource leveling is a requirement of the planning process and jxProject provides very accurate resource leveling capabilities.

Resource leveling is not resource optimization.  A project plan that has no over allocated resources does not mean the plan makes good use of the resources. The optimization of a project plan entails the identification of unused resource work time and identifying tasks that can be scheduled into the available time. JxProject provides an automated resource optimizing capability which reschedules tasks into available work time. In addition, jxProject contains several other tools/features to assist the user in further optimization.

Resource leveling and optimization are achieved through the task ranking capabilities of jxProject.

Rank and Resource Leveling: The rank is used to determine the order/priority in which resource work time is allocated. Example: Task-A (Rank 5) and Task-B is (Rank 6). Task-A, has priority over Task-B with regards to resource work time as Task-A has a LOWER rank value.

In the above example, the rank of Task-B will delay its start, relative to Task-A, ONLY if ALL of the following conditions are true:

  1. Resource leveling is enabled

  2. Neither of the tasks is a summary task

  3. The tasks have at least one resource in common

  4. Simultaneously scheduling Task-A and Task-B will result in an overallocation of at least one the resource(s) in common

  5. The earliest possible start time of Task-B is sooner than the finish time of Task-A

Note: In situations where there are multiple tasks with partially assigned resources, the partial allocations are additively considered. Example: Task-A (Rank 5), Task-B (Rank 7), Task-C (Rank 14), Task-D (Rank 22), all have resource Bob assigned at 30% to each of the four tasks and all of the tasks are occurring simultaneously. The task with the highest rank value(Task-D) will be pushed out to avoid overallocation, but the first three tasks will be free to start at their earliest possible times. {(3*30 = 90%) < 100%} is OK, but {(4*30 = 120%) > 100%} would not be allowed by the resource leveler.

Task Rank Display: The rank of a task is visible in the Gantt Table column labeled Rank. It is displayed as in the following example: “23 – 19 > 11”. The first value(23) is the rank, the second value(19) is the lowest rank value for this task before hitting a hard constraint. The last value(11) is the absolute lowest rank value that this task can assume given the project plan structure. Often you will see “*” in the rank display, for example: “27 * > 23”. The * means that the value is the same as the value to the left. In this example, the * represents 27. The task ranked number 1 will always be seen as: “1 * *”, as it is already at its lowest possible value.

Rules of Rank:

By default, tasks are ranked from top to bottom starting at 1 (one) and incrementing by one for each task.

  1. The rank of each task is a unique positive integer value.

  2. A successor task always has a higher rank value than its predecessor(s).

  3. A summary task always has a rank value that is one higher than the highest rank value of its child tasks.

  4. The structure of the project plan, task parent/child relationships and task links [FS, FF, SF, SS, RU] are subject to the rules of rank and no changes to the rank of a task can violate these rules.

  5. The rank of a task will not change unless a change to the project plan structure requires it in order to conform with the above rules, or the user initiates a change of rank by the means outlined below.

How to alter the rank of a task:

  1. Change the structure of the project plan: Task parent/child relationships or task links [FS, FF, SF, SS, RU]

  2. Use Pseudo link types Ra+ and Ra- in the Gantt Chart.

  3. Edit the rank cell value in the Gantt Table.

  4. Initiate the resource optimizer from the Gantt View. If an optimization opportunity is identified, it will alter the rank of tasks to achieve the optimization.

Link Type RU :

This is a Resource User link and can be thought of as a soft link. The only constraint that this link enforces is that the successor task must have a higher rank value than the predecessor task. This link can be used to ensure that one task has priority over another task in any competition for resources.

Pseudo link types Ra+ and Ra- :

The rank of a task is only significant in its relationship to other tasks that have resource(s) in common. The pseudo links provide a familiar method of altering the rank of a task by specifying that a specific task is to be ranked later than another task. For these operations, the desired result is that the successor task is assigned a higher rank value than the predecessor. To use these tools, the user must be in the Gantt view, and select the Ra(+/-) link type from the “link type” pull down on the tool bar. Then click down on the predecessor and drag to the successor and release the mouse. This is the same method/interactoin as creating hard link dependencies, but no link is created in this operation, only changes to the ranks of the tasks.

Rank Adjustment Positive [Ra+]: For this Pseudo link type, the successor task rank is increased to be one higher than the rank of the predecessor task. This operation is used to push the successor forward in the project plan. To schedule the successor at a later date.

Rank Adjustment Negative [Ra-]: For this Pseudo link type, the predecessor task rank is decreased to be one lower than the rank of the successor task. This operation is used to pull the predecessor back in the project plan. To schedule the predecessor at an earlier date.

There are many situations where the results of these operations will differ from what you might expect. If the rank of the successor task is greater than the rank of the predecessor task, no changes will be made as the ranks already comply with the action. If the Pseudo link would form a circular constraint violation if it were a real link, then no rank changes can be made. If performing an Ra+ operation, and the pseudo link successor has one or more “real” successor tasks ranked between the tasks of the pseudo link, then those successor task(s) will be pushed forward in the schedule along with the pseudo link successor. This will drop the pseudo predecessor back in the schedule further than you might have expected. There are times when the results of these two operations (Ra+, Ra-) will produce the same result.

When the rank of one task is changed, it necessitates the change to the rank of at least one other task. The rank is the mechanism by which the tasks compete for the resources to get them done. The structure of the project plan dictates how close the rank changes attempt to make can actually be implemented.

After you have attempted a pseudo link operation, check to see that the successor rank is higher than the predecessor rank, if it is, then the operation was successful, even if the results were not quite what you expected.

Editing the rank cell value in the Gantt TreeTable:

To edit the rank in the Gantt Table, click on the rank cell you wish to edit and you will be presented with a spinner editor. You can increase/decrease the value and then push enter to submit the change. The resulting rank might not always be what you expected as any changes must comply with the rules of rank. If you attempt to set the rank of a task to the highest possible value, this will not be possible if there are one or more successors to the task. In this case the rank will be set as high as possible within the rules of rank.

If you attempt to set the rank of a task to the same value as the rank of another summary task, the resulting rank will be one higher, or lower, than what you requested. This is because a summary task always takes all of child tasks along with it, you are always dealing with more than one task when working with ranks of summary tasks.

The Resource Optimizer [The “Op” button]:

To initiate the optimizer the user must click the “OP” button on the tool bar. This will start a process to identify and reschedule a task to an earlier start date within the following restrictions:

  1. The rescheduling of the task must result in the task starting earlier

  2. The rescheduling of the task can not cause the start date of any other task to be increased.

  3. The optimizer can only alter rank values. No other modifications are allowed.

Each push of the button performs, at most, a single task optimization within the above restrictions. When a task is successfully moved by the optimizer, it often has a cascade effect causing other tasks to be rescheduled earlier. This is considered a desirable result. If no qualified optimizations are identified by the optimizing process, no changes are performed.

All changes performed by the optimizer are subject to undo/redo.

Push the “Op”button as often as you like. The free version of jxProject has a limit to the number of optimizations that will be performed. Once this is exceeded the button will be disabled. See the purchase/buy section of jxProject.com for more information.

Resource Optimizing Strategy:

The resource optimizer described above does not guarantee that your project plan is fully optimized with regard to resource utilization. It is a powerful tool, but it operates under a very tight set of restrictions and only makes changes where there are no trade off decisions to be made. For example, if the optimizer finds a task that requires four months of work can be scheduled 6 months sooner, but moving the task would overlap another task by 1 minute, it won't move the task!

The project manager needs to perform any rank changes that require “trade off” decisions. From the tools described above, the best are the Ra- pseudo link and undo/redo. Working to identify tasks that can happen sooner than they are currently scheduled is a natural way for a project manager to think. Pulling tasks back in the schedule often yields results that are closer to what the user expects. Also, both of the pseudo link tools make “relative” changes. Changing the rank of one task relative to another is more predictable than setting an absolute rank value using the table cell editor.

The undo/redo is an important tool as it allows the user to clearly observe the impact of the last change. You can pop back and forth with the undo/redo and get a “before” and “after” graphical, almost animated, view of the impact on the entire project plan.


I want to share some more of my ideas for further resource optimization in jxProject. I'm doing this in hopes of getting feedback/ideas from users.

I really like the way this has come together. You can build any kind of project plan, have it fully resource leveled and have some good optimization tools. However, I feel there is some opportunity for improvement in helping the user/project manager locate more optimization opportunities. Here's an idea: The resource view shows the calendars and resources and their schedules and the assigned tasks. In that view you can clearly see the gaps (work time with no assigned task) in the resource schedules, but you can't reschedule tasks in that view or see task dependencies. I'm thinking it would be helpful to allow the user to reschedule tasks by drag/drop in the chart. But, I would need to show the user what changes were possible for each of the tasks ... show the early start date and late finish dates, float, stuff like that. Maybe even allow tasks to be assigned to different resources in that view. If the user knew the early start for each task, they would know how early they could be scheduled. It would allow the project plan to be developed/optimized from the resource and project perspectives. I think it would be more useful than any algorithms I could develop.

Ok users, discuss amongst yourselves. Let me know what you think. :-)

Copyright ©2002-2012 jxProject Company