Finding the sweet spot in resource workload
ISE Magazine Volume : 50 Number: 4
By James R. Holt and Robin Clark
Algorithm combines efficiency and effectiveness for project management
Resource overload is a primary cause of bad multitasking and delay in projects. It is very difficult to determine the workload expected to be done by any particular resource at any moment in time. But a simple algorithm can provide a “good enough” indicator to give management the information needed to start or delay additional projects.
In a busy project organization, it is impossible to predict the starting and ending times of individual tasks. However, it is possible to know the amount of planned, uncompleted work flowing toward key resources. By controlling the amount of work a resource must perform over a period of time, management can create a consistent, stable workload that gives faster and more predictable results.
This article introduces a Workload Index to indicate how much work each skill type is required to do during a fixed period in the near future:
Workload Index = (Sum of expected task durations for all uncompleted tasks requiring a specific skill)/(Number of workers with that skill)/(Average length of projects)
Queuing theory in projects
In projects, tasks move from resource to resource. Each move puts the tasks into a new queue for the next resource. Project resources that are loaded to 90 percent make tasks wait at least three times longer than the resources loaded to only 75 percent. This very significant delay happens when just a little too much work is assigned. By choking back the release of work just a bit, projects can be completed much faster. And the customer receives the value the project provides much sooner.
Some projects are long and some are short. The Workload Index examines all the active projects of an organization and calculates a simple average of the longest planned length of the projects. This simple average is the sum total of the planned length of each project divided by the number of projects.
The algorithm adds together the expected task durations of all uncompleted tasks to be done by a specific skill within the “look ahead period.” It includes tasks wherever they are within the project execution (this includes tasks yet to be done that are not yet ready for work by the resource). Tasks that are partially completed are considered uncompleted.
There is no need to know the exact work schedule nor the sequence of work. Rather, the Workload Index gives a general indication of the backload of uncompleted work.
Adding priorities, handling difficult tasks
In the simulations reported so far, the workers performed the tasks in a multitasking way. If a worker had several tasks in a queue, each day the worker would select the first task in the queue and work on it (roll the dice). The task was completed one-sixth of the time. If the task was not finished that day, that task went to the back of the queue. The next day, the worker would select the first task at the front of the queue. This type of multitasking continued throughout the simulation.
What if each worker was told every day which task in their queue was the most important task for the whole organization? If the worker could focus on the most important task continually until it was complete (work on the same task day after day until it was completed) before working on other tasks in the queue, things should improve. Right?
The priority system used in this test gave first priority to the tasks of projects with the earliest start date. (This arbitrary priority system shows what would happen with almost any priority system.)
In projects, there are lots of unknowns. That is why the beta distribution is used in estimating task durations. This simulation used rolling a fair die to get a six (a one-sixth chance of completion each day). While the average time to roll a six logically seems to be six rolls, the beta distribution shows it can frequently take more than 12 rolls to get a six, and too often more than 20 rolls (try this yourself).
Any task in the project could have bad luck and take much, much more time than expected. And almost any task that takes significantly too long will delay the project. If there were a way to cut off the long tail of the beta distribution, things would be much better.
The final test simulations considered the possibility of having an additional “expert resource” available to assist any worker who had not completed his or her task within six rolls. The expert would be someone who is qualified to assist any skill. The expert adds a 10th person to the resource pool. However, no specific assignment is given to the expert. Whenever a worker was having trouble with a task (has not completed the task after six rolls), the expert would “join” the troubled worker. The worker and the expert would both work on the priority task. They would both roll their dice each day until one of them gets a six (effectively doubling the probability of completion to one-third).